Wir geraten in eine interessante Diskussion und spalten uns in zwei Lager. Mich interessieren alle besonderen Probleme mit einer der Ideen oder Fallstricke, die wir möglicherweise übersehen. Eigentlich alles, was uns bei der Entscheidungsfindung helfen oder uns auf Dinge aufmerksam machen kann, die wir nicht berücksichtigen. Ich weiß, dass dies die „Keine Meinung“-Regel ein wenig umgeht, aber ich hoffe, dass es trotzdem eine akzeptable Frage ist. Entschuldigen Sie auch die Länge, es gibt ziemlich viele Nuancen.
1) Eine Seite (meine – ich bin nicht unvoreingenommen) findet das unveränderliche Servermodell für Cloud-Systeme sehr interessant. Zu diesem Zweck haben wir einen Prototyp entwickelt, bei dem wir alle Komponenten unserer Infrastruktur in Docker verschoben haben. Unsere benutzerdefinierten Anwendungen werden über Jenkins direkt in Docker-Images erstellt, die in einem lokalen Docker-Register bereitgestellt werden. Dann haben wir eine große Anzahl von Ansible-Rollen und ein Playbook erstellt, das in der Lage ist, einen leeren Server zu erreichen, Docker zu installieren und Docker dann anzuweisen, alle Container nach Bedarf zu installieren. Nach ein paar Minuten ist die gesamte App und ihre gesamte unterstützende Infrastruktur verkabelt und funktioniert – Protokollierung, Überwachung, Datenbankerstellung/-befüllung usw. Die fertige Maschine ist eine in sich geschlossene QA- oder Entwicklungsumgebung mit einer exakten Kopie der Anwendung. Unser Plan, dies zu skalieren, wäre, neue Playbooks zu erstellen, um neue AWS-Server aus einem vertrauenswürdigen Basis-AMI (wahrscheinlich ein sehr einfaches Image) zu erstellen, rollierende Bereitstellungen der Produktionsanwendung durchzuführen, um Konfigurationsmanagement und Releases zu handhaben, und Server im Allgemeinen nie wieder zu bearbeiten – sie einfach neu zu erstellen. Mir geht es nicht darum, ob das, was ich beschrieben habe, in der Praxis funktioniert, sondern nur darum, dass es ein vernünftiges Modell ist.
2) Das andere Lager möchte Puppet für die Konfigurationsverwaltung verwenden, Ansible für die Bereitstellung unserer benutzerdefinierten Anwendungen, die Tarballs sind, die aus unserem Build-Prozess generiert werden, Foreman für die Auslösung und Verwaltung des gesamten Prozesses und Katello für eine gewisse Basis-Image-Verwaltung. Bei Releases würde Puppet die Konfiguration nach Bedarf ändern und Ansible aktualisierte Komponenten mit einer gewissen Koordination durch Foreman bereitstellen. Server würden relativ schnell erstellt, wenn wir neue bräuchten, aber es ist nicht beabsichtigt, sie als Teil des Standardprozesses entbehrlich zu machen. Dies kommt dem Phoenix-Server-Modell näher, hat jedoch eine lange Lebensdauer.
Meine Frage läuft also darauf hinaus: Ist das unveränderliche Servermodell mit den oben beschriebenen Tools tatsächlich so realistisch, wie es scheint? Mir gefällt die Idee, dass wir bei unserem Staging-Prozess buchstäblich einen vollständigen Klon der Live-Anwendungen erstellen können, ihn von der Qualitätssicherung bearbeiten lassen und dann nur noch den Datenbankspeicher und einige DNS-Einstellungen ändern, um ihn live zu schalten.
Oder versagt das unveränderliche Servermodell in der Praxis? Wir haben viel Erfahrung sowohl mit AWS- als auch mit Cloud-Umgebungen, daher ist das nicht wirklich das Problem – es geht eher darum, wie man eine einigermaßen ausgereifte App in Zukunft zuverlässig bereitstellen kann. Dies ist von besonderem Interesse, da wir recht häufig neue Versionen herausbringen.
Wir haben Ansible, das die meisten notwendigen Dinge erledigt, außer EC2-Server für uns zu erstellen, und das ist nicht schwer. Ich habe Schwierigkeiten zu verstehen, warum Sie in diesem Modell überhaupt Puppet/Foreman/Katello BRAUCHEN. Docker ist wesentlich sauberer und einfacher als benutzerdefinierte Bereitstellungsskripte in wirklich jedem Tool, das ich kenne. Ansible scheint viel einfacher zu verwenden als Puppet, wenn Sie sich keine Gedanken mehr darüber machen müssen, sie vor Ort konfigurieren zu müssen, und sie einfach mit der neuen Konfiguration neu erstellen können. Ich bin ein Fan des KISS-Prinzips – insbesondere in der Automatisierung, wo Murphys Gesetz grassiert. Je weniger Maschinen, desto besser, meiner Meinung nach.
Alle Gedanken/Kommentare oder Vorschläge zu diesem Ansatz sind sehr willkommen!
Antwort1
In unserem Unternehmen haben wir Puppet erfolgreich auf der Legacy-Infrastruktur des Kunden implementiert. Wir verwenden auch Docker-Container, um einen dedizierten Dienst auszuführen (der eigentlich eine alte Anwendung ist, die so zugeschnitten und verdreht wurde, dass sie in Container passt).
Ich war nicht glücklich mit Containern, als ich das erste Mal mit ihnen zu arbeiten begann (ja ... eine 30-KB-App wird zu einem 200 MB großen Image), aber als ich nach einem kleinen Desaster die gesamte Umgebung neu erstellen musste, änderte ich meine Meinung. Ich denke, Docker wurde genau dafür erfunden: schnelle und häufige Bereitstellungen ohne Sorgen um die Serverkonfiguration. Wenn Sie die Container richtig entwerfen, können Sie problemlos zwischen Cloud-Anbietern, Entwickler-Laptops und Colocation-Rechenzentren wechseln. Denn alles, was Sie brauchen, ist eine Vanilla-Linux-Box mit Docker-Daemon.
- In Szenario 1) haben Sie alles an einem Ort (ich meine an einem, weil Sie mit Docker Code UND Konfiguration im selben Repository haben), einfach zu verwalten, zu lesen und bereitzustellen.
- Im Szenario 2) müssen Sie Konfigurationsteile für 3 verschiedene(!) Tools in einem Repo und Anwendungscode in dem anderen speichern, was die Sache komplizierter macht
Ich habe in meinem vorherigen Projekt auch Puppet verwendet und meine bisherige Erfahrung ist, dass ein unveränderlicher Server eher mit Docker als mit Puppet oder Chef erreicht werden kann. Ich glaube, dass Konfigurationsmanagement-Tools für Cloud-Anbieter nützlicher sind als für Entwicklungsteams.
Antwort2
Hier sind meine 2 Cent.
Die beiden von Ihnen vorgeschlagenen Optionen sind gültige Optionen, um (eine Art) Unveränderlichkeit zu erreichen.
Ich denke, Sie sollten die Option wählen, mit der Sie sich am wohlsten fühlen.
Aus dem, was Sie schreiben, scheint jedoch noch kein Konsens zu bestehen.
Vielleicht ist dann eine dritte Option erforderlich? ;)
Allerdings ist Unveränderlichkeit kein Ziel, sondern ein Mittel, um andere Eigenschaften sicherzustellen (kein Konfigurationsdrift, bessere Stabilität, ...).
Ich würde meine Ziele klar formulieren, einige Metriken zur Validierung festlegen und einige Tests mit den beiden Optionen durchführen. Sie hätten dann einige Zahlen, um die Option auszuwählen, die am besten zu Ihrem Unternehmen passt.
Viel Glück!