Sind Konfigurationsmanagement-Tools als Bereitstellungstools geeignet?

Aus meiner Antwort auf die Frage: Wie kann DevOps helfen, Software Escrow-Verfahren zu verbessern? Tensibai hatte die Frage:

Was würde Capistrano auf Puppe oder Koch erfordern?

Meine Antwort war, einen Link zu Noah Gibbs 'Artikel "Brauchen wir sowohl Capistrano als auch Chef?" . Persönlich stimme ich immer noch der Ansicht von Noah zu, dass es am besten geeignet ist,

• Verwenden Sie für Bereitstellungen ein spezielles Bereitstellungstool wie Capistrano.
• Verwenden Sie ein spezielles Konfigurationsmanagement-Tool wie Chef für das Konfigurationsmanagement.

Der grundlegende Ansatz, mit dem jeder Werkzeugtyp seine Aufgabe erfüllt, ist sehr unterschiedlich:

• Konfigurationsmanagement-Tools - dienen dazu, den gewünschten Status eines Systems zu erstellen und beizubehalten. Sie sind von Natur aus idempotent. Beispiele für Konfigurationsverwaltungstools sind Chef , Puppet , Ansible , PowerShell DSC und Salt Stack .

• Deployment Tools - sind über die Bereitstellung Versionen von Software in eine Hosting - Umgebung, die sie bieten Funktionen , um mehrere Versionen der Software auf mehreren Maschinen zu warten und zu verwalten , welche Version ist „aktuell“, sie sind von Natur unbedingt in der Natur. Beispiele für Bereitstellungstools sind Capistrano , Octopus Deploy , Deployer und Command.io .

Ich glaube, dass Configuration Management Tools die Aufgabe von Bereitstellungstools übernehmen können, und im Fall von Immutable Infrastructure sind sie das am besten geeignete Tool für diese Aufgabe, da Softwareversionen auf dem Ziel nicht gewartet werden müssen.

Frage: Sind Konfigurationsmanagement-Tools wie Chef, Ansible und Puppet so weit gereift, dass sie sowohl das idempotente als auch das imperative Modell erfüllen können?

In diesem Zusammenhang sollte der typische Rat sofort anwendbar sein: Verwenden Sie das richtige Werkzeug für den Job.

Aber dann kann man auch heute nicht mehr ignoriert die fast virulent Tendenz von Software - Tools - Funktionalität in mehr oder weniger verwandten Bereiche zu erweitern und tatsächlich wurden Toolset aus verschiedenen Gründen: cool - Funktion (en) zu haben, die Kundenbasis zu erweitern, amass mehr Einnahmen, usw.

Beispielsweise enthalten viele Dateiverwaltungswerkzeuge Bildanzeigefunktionen und viele Bildverarbeitungswerkzeuge Dateiverwaltungsfunktionen. Sie können Dateien verschieben und Bilder mit einem der beiden Tools anzeigen, häufig gleich gut.

Aus diesem Grund ist es durchaus möglich, dass ganze Teile des Softwareentwicklungsprozesses von mehreren Tools (Sets) abgedeckt / überlappt werden, selbst wenn sich deren Hauptmerkmale / -fähigkeiten unterscheiden.

Es kommt also wirklich auf die genaue Funktionalität an, die Sie in Ihrem speziellen Prozess erreichen möchten, und wie gut das eine oder andere Werkzeug die Arbeit in Ihrem Kontext erledigt . Subjektivität / Vorlieben / Bequemlichkeit inklusive.

Diese Frage in erster Linie meinungsbasiert stellen;)

Konfigurationsmanagement-Tools werden verwendet, um ein System in einen bekannten Zustand zu versetzen. Bereitstellungstools stellen neue Programmdateien und Programmdaten auf einem System bereit. Letztendlich bieten beide Arten von Werkzeugen eine Kombination aus:

• Bestimmen Sie den aktuellen Status des Systems.
• Übertragen Sie Dateien auf das System.
• Hinzufügen oder Ändern persistenter Daten (z. B. Konfigurationsdateien, Datenbankdaten, Registrierungseinstellungen)
• Programme starten oder neu starten.

Konfigurationsverwaltungstools verfügen über deklarative Sprachen, die den Status des Systems angeben. Bereitstellungstools verfügen über zwingende Sprachen, die das System anweisen, Dinge zu tun. Eine DevOps-Person muss beides tun.

Mit dem Bereitstellungstool Capistrano ist es umständlich, das System anhand seiner Sprache anzuweisen, sicherzustellen, dass der Webserver aktiv ist. Sie müssen einen Befehl ausgeben, um den Webserver neu zu starten, und einen anderen, um zu überprüfen, ob der Webserver aktiv ist. Es ist ein Problem, den Webserver in einen bekannten Zustand zu versetzen.

Mit dem Konfigurationsmanagement-Tool Ansible ist es umständlich, einen Webserver neu zu starten. In der Sprache können Sie dem Webserver mitteilen, dass er "aktiv" sein soll. Wenn Sie jedoch ausdrücklich möchten, dass er neu gestartet wird, müssen Sie seinen Status auf "neu gestartet" setzen. Es gibt jedoch keine einfache Möglichkeit, zu überprüfen, ob der Webserver neu gestartet wurde. Dies ist ein Problem in Ansible, um einmalige Vorgänge zu ermöglichen.

Einige Leute bevorzugen es, beide Arten von Arbeiten mit einem Werkzeug auszuführen und an den rauen Kanten zu arbeiten. Andere Leute bevorzugen zwei Werkzeuge, um fast dasselbe zu tun, aber ohne Ecken und Kanten. Um die Frage zu beantworten, ist "Angemessenheit" Geschmackssache. Diese Antwort erklärt warum.

TL; DR : Verwenden Sie einfach Ansbile, es ist sowohl ein Konfigurations- als auch ein Bereitstellungstool :)

Es gibt verschiedene Arten der Bereitstellung:

• Anwendungsbasiert (Dateien, Archivpakete)

• Container- basiert (einschließlich VMs, Habitat, LXC, Docker)

• Funktionsbasiert (Micro Services / Lambdas / Funktionen)

Ich gehe davon aus, dass wir in diesem Fall nur über Anwendungsupdates auf Servern sprechen.

Für die Bereitstellung müssen zwei Dinge geschehen:

1. Richtige Dateien oder Pakete müssen auf den Server verschoben werden.
2. Konfigurations- und Servicestatus müssen sich ändern.

Für (1) können Sie nun mehrere Strategien verwenden:

• Artefakt-Repositorys / Synchronisierung
• Paket-Repositories / Paket-Manager
• Versionskontrollsystem / Aktualisieren + Kompilieren (optional)
• Dateiübertragungsprotokolle (scp, rsync, ftp)
• Bereitstellungstools

Für die (2) können Sie verwenden:

• Konfigurationsverwaltungstools
• Bereitstellungstools

Die Bereitstellungstools sind zwar eine Möglichkeit, die Bereitstellung in einem Schritt durchzuführen, sie sind jedoch nicht immer die beste Strategie. Manchmal möchten Sie eine Kombination dieser Methoden für die Bereitstellung verwenden. Sie verwenden höchstwahrscheinlich bereits Paketmanager, zumindest auf Ihren Servern. Sie führen höchstwahrscheinlich ohnehin Konfigurationstools aus. Das Problem mit einigen der Konfigurationstools war eine ordnungsgemäße Orchestrierung zwischen mehreren Servern, aber jetzt können sogar Chef und Puppet dies recht gut. Ansible war immer gut darin.

Aus persönlicher Erfahrung habe ich alle Kombinationen verwendet, aber derzeit verwenden wir Capistrano für die Bereitstellung und Ansible Sync für das Konfigurationsmanagement sowie VCS- und Paket-Repositorys für Dateiübertragungen. Es gibt jedoch Probleme mit Capistrano, und wir planen, von diesem zu wechseln Unify on Ansible für Bereitstellung, Wartung und Konfigurationsverwaltung.

Die Bereitstellung von Anwendungen ist schwierig zu bestimmen, da sie viele Unterprobleme aufweist. Konfigurationsverwaltungssysteme eignen sich hervorragend zum Modellieren von Aufgaben, die konvergent sind und mit "dem gewünschten Status des Systems" arbeiten. Im Zusammenhang mit der App-Bereitstellung eignet sich dies hervorragend für Dinge wie das Bereitstellen von Bits auf einem Computer, das Verwalten von Konfigurationsdateien und das Einrichten von Systemdiensten. Was extrem schlecht ist, sind Dinge, die von Natur aus prozedural sind, insbesondere Datenbankmigrationen und Neustarts von Diensten. Normalerweise versuche ich, die konvergente Logik in Chef zu integrieren und ein externes prozedurales Tool (in meinem Fall normalerweise Fabric) die wenigen verbleibenden Bits verarbeiten zu lassen sowie die tatsächlichen Konvergen zu sequenzieren.

Grundsätzlich sollten Sie beide für die Teile verwenden, in denen sie am besten sind.

Für Software und die Bereitstellung von Code auf einen vorhandenen Server oder in einem Docker Behälter, die Antwort ist relativ einfach - Nein, Sie nicht brauchen beides, aber Sie könnten beide wollen , wenn ein anderes Werkzeug oder Nutzwert fügt hinzu und ist das richtige Werkzeug für den Job Bei der Bereitstellung von Servern und Betriebssystemen wird es jedoch komplizierter.

Ein Mehrwert einer DevOps-Mentalität besteht darin, die Infrastruktur als Code zu behandeln und häufig virtuelle Maschinen oder sogar Bare Metal in einer stark elastischen Umgebung bereitzustellen oder zu zerstören. Ihr Konfigurationsverwaltungssystem kann Ihren Server nicht einfach netbooten und starten und kann Repositorys, Pakete und Updates / Patches während und nach Bereitstellungen oder in einigen Fällen Lizenzen und Berechtigungen nicht für Sie verwalten.

Für Amazon Web Services ist dies größtenteils bequem über APIs zu verwalten, aber für diejenigen von uns, die ihre eigenen Rechenzentren verwalten müssen, ist dies keine Option. Aus diesem Grund war es für das Foreman- Projekt (und Red Hat, das dies umbenennt ) erforderlich, Katello , Candlepin und einen Konfigurationsmanager wie Ansible, Foreman oder Puppet bei der Bereitstellung des Katello-Szenarios zusammen zu bündeln .

Während Sie möglicherweise in der Lage sind, Konfigurationsmanagement-Tools für Software-Code-Bereitstellungen auf der Dev-Seite des Hauses zu verwenden, gibt es auf der Ops-Seite mehrere Fälle, in denen die Antwort ein klares "Nein" lautet, Konfigurationsmanagement-Tools nicht geeignet als Einsatzwerkzeug "Dies würde eine ernsthafte Neuerfindung des Rades erfordern und ist unpraktisch. Sie müssen stattdessen Ihre Konfigurationsverwaltungstools verwenden, um Bereitstellungen in einem anderen Tool zu initiieren.