Wir stoßen auf einen interessanten Streit und fallen in zwei Lager. Ich interessiere mich für bestimmte Probleme mit Ideen oder Fallstricken, die uns möglicherweise fehlen. Wirklich alles, was uns helfen kann, eine Entscheidung zu treffen oder auf Dinge hinzuweisen, die wir nicht berücksichtigen. Ich weiß, dass dies die Regel "Keine Meinung" ein wenig umgeht, aber ich hoffe, dass dies immer noch eine akzeptable Frage ist. Entschuldigung auch für die Länge, es gibt einiges an Nuancen.
1) Eine Seite (meine - ich bin nicht ohne Vorurteile) findet das unveränderliche Servermodell für Cloud-Systeme sehr interessant. Zu diesem Zweck haben wir Prototypen entwickelt, um alle Komponenten unserer Infrastruktur in Docker zu verschieben. Unsere benutzerdefinierten Anwendungen werden über Jenkins direkt in Docker-Images integriert, die in einer lokalen Docker-Registrierung bereitgestellt werden. Anschließend haben wir eine große Anzahl von Ansible-Rollen und ein Playbook erstellt, mit dem Sie einen leeren Server erreichen, Docker installieren und Docker anweisen können, alle Container nach Bedarf zu installieren. Nach ein paar Minuten ist die gesamte App und die gesamte unterstützende Infrastruktur verkabelt und funktionsfähig - Protokollierung, Überwachung, Datenbankerstellung / -auffüllung usw. Die fertige Maschine ist eine eigenständige QS- oder Entwicklungsumgebung mit einer genauen Kopie der Anwendung. Unser Plan, dies zu skalieren, besteht darin, neue Playbooks zu erstellen, um neue AWS-Server aus einem vertrauenswürdigen Basis-AMI zu erstellen (wahrscheinlich ein sehr nacktes Image), fortlaufende Bereitstellungen der Produktionsanwendung durchzuführen, um das Konfigurationsmanagement und die Releases zu verwalten, und Server im Allgemeinen nie wieder zu bearbeiten. mach sie einfach neu. Es geht mir nicht darum, das, was ich beschrieben habe, in die Praxis umzusetzen - nur wenn es ein vernünftiges Modell ist.
2) Das andere Camp möchte Puppet für das Konfigurationsmanagement verwenden, Ansible für die Bereitstellung unserer benutzerdefinierten Anwendungen, bei denen es sich um Tarballs handelt, die aus unserem Erstellungsprozess generiert wurden, Foreman für die Auslösung und Verwaltung des gesamten Prozesses und Katello für eine gewisse Basis Bildverwaltung. In Releases würde Puppet die Konfiguration nach Bedarf ändern und Ansible aktualisierte Komponenten mit einem gewissen Maß an Foreman-Koordination bereitstellen. Server würden relativ schnell gebaut, wenn wir neue benötigen würden, aber die Absicht ist nicht, sie als Teil des Standardprozesses verfügbar zu machen. Dies ist näher am Phoenix-Server-Modell, wenn auch mit einer langen Lebensdauer.
Meine Frage lautet also wirklich: Ist das unveränderliche Servermodell mit den Tools, wie ich sie oben beschrieben habe, tatsächlich so realistisch, wie es scheint? Ich mag die Idee, dass unser Staging-Prozess buchstäblich einen ganzen Klon der Anwendungen in Live erstellen kann. Lassen Sie die Qualitätssicherung ihn hämmern und drehen Sie dann einfach den Datenbankspeicher und einige DNS-Einstellungen um, um ihn live zu schalten.
Oder schlägt das unveränderliche Servermodell in der Praxis fehl? Wir haben viel Erfahrung mit AWS- und Cloud-Umgebungen, daher ist dies nicht wirklich das Problem - es geht vielmehr darum, wie eine einigermaßen ausgefeilte App in Zukunft zuverlässig bereitgestellt werden kann. Dies ist von besonderem Interesse, da wir ziemlich häufig veröffentlichen.
Wir haben Ansible, das die meisten Dinge erledigt, außer EC2-Server für uns zu erstellen, und das ist nicht schwer. Ich habe Probleme 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 erkennen kann. Ansible scheint viel einfacher zu verwenden zu sein als Puppet, wenn Sie sich keine Gedanken mehr darüber machen müssen, ob Sie sie vor Ort konfigurieren müssen, und sie einfach mit der neuen Konfiguration erneut erstellen müssen. Ich bin ein Fan des KISS-Direktors - besonders in der Automatisierung, in der Murphys Gesetz weit verbreitet ist. Je weniger Maschinen, desto besser IMO.
Alle Gedanken / Kommentare oder Vorschläge zum Ansatz wäre sehr dankbar!