3 Strategien für automatisierte Produktionsbereitstellungen mit Docker

Docker ist ein beliebtes Entwicklungstool, da es das Starten isolierter Instanzen Ihrer Anwendung mit einer reproduzierbaren Konfiguration vereinfacht. Es kann auch in der Produktion verwendet werden, wo es sicherstellt, dass Live-Bereitstellungen mit Ihrer Entwicklungsumgebung identisch sind.

Einen Container in Produktion zu bringen ist nicht immer so einfach wie das Ausführen von docker run auf Ihrem lokalen Rechner. Es ist keine gute Idee, Images manuell in eine Registrierung zu verschieben, eine Verbindung zu einem Remote-Docker-Host herzustellen und Ihre Container zu starten. Dies ist auf menschliches Eingreifen angewiesen, daher ist es zeitaufwändig und fehleranfällig.

In diesem Leitfaden sehen wir uns drei verschiedene Strategien an, die Sie verwenden können, um Docker-Bereitstellungen einfach zu automatisieren und eine konsistente Konfiguration aufrechtzuerhalten. Diese Ansätze können als Teil einer CI-Pipeline skriptgesteuert werden, um jedes Mal, wenn sich Ihr Code ändert, neue Container zu starten. Sie müssen Ihre Docker-Images erstellen und sie als erste Phase Ihres Skripts in eine Registrierung übertragen. Verwenden Sie dann eine der folgenden Techniken, um das Image abzurufen und Container in Ihrer Produktionsumgebung zu starten.

1. Docker Compose über SSH

Mit Docker Compose können Sie mehrere Container mit einem einzigen Befehl starten. Darüber hinaus wird Compose über eine YAML-Datei konfiguriert, die Ihnen bei Versionsänderungen hilft und reproduzierbare Bereitstellungen garantiert.

Möglicherweise haben Sie Compose bereits als lokales Entwicklungstool verwendet. Sie müssen eine docker-compose.yml erstellen Datei in Ihrem Arbeitsverzeichnis und fügen Sie dann einen oder mehrere services hinzu die die zu startenden Container definieren:

version: 3
services:
  app:
    image: example.com/app:latest
    ports:
      - 80:80
  database:
    image: mysql:8.0
    expose:
      - 3306

Sobald Sie eine Compose-Datei haben, verwenden Sie docker-compose up -d Befehl zum Starten Ihrer Container. Wenn Sie die Datei ändern, wiederholen Sie den Befehl, um Ihre Änderungen zu übernehmen. Compose aktualisiert oder ersetzt Container, um den neuen deklarierten Zustand zu erreichen.

Hinzufügen des --pull Flag weist Compose an, zu versuchen, aktualisierte Images abzurufen, bevor Container gestartet werden. Sie können auch --force-recreate verwenden um die Erstellung neuer Container zu erzwingen, selbst wenn sich ihre zugrunde liegende Konfiguration nicht geändert hat.

Wie bezieht sich all dies auf Produktionsbereitstellungen? Das bedeutet, dass Sie Compose als Teil Ihrer CI-Pipeline verwenden können, um mühelos Container zu starten, die den Zustand erfüllen, den Sie in Ihrer docker-compose.yml deklarieren Datei. Ausführen von docker-compose up -d --pull in jeder Pipeline gibt Ihnen eine Reihe von Containern, die jeweils die neueste Version ihres Images ausführen.

Es gibt mehrere Möglichkeiten, wie Sie diese Methode implementieren können. Die einfachste und sicherste Route besteht darin, Docker und Compose auf Ihrem Produktionshost zu installieren und dann über SSH eine Verbindung damit herzustellen. Sie müssen die Einstellungen Ihres CI-Anbieters verwenden, um SSH-Anmeldeinformationen als Variablen zu speichern, auf die Ihre Pipeline zugreifen kann. Anschließend konfigurieren Sie den SSH-Client in Ihrer Pipeline und kopieren die docker-compose.yml Datei auf Ihren Remote-Host und führen Sie  docker-compose up aus Befehl.

Hier ist ein Beispielskript:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo $SSH_PRIVATE_KEY | ssh-add -
echo $SSH_HOST_KEY > ~/.ssh/known_hosts
scp docker-compose.yml:[email protected]:/home/ci-user/docker-compose.yml
ssh -t [email protected] docker-compose up -d

Alternativ können Sie Docker-Kontexte verwenden, um die Compose-Binärdatei lokal in der Umgebung Ihrer Pipeline auszuführen. Dazu müssten Sie den Docker-Socket auf Ihrem Remote-Host verfügbar machen; Da dies ein Sicherheitsrisiko darstellen kann, ist der Ansatz in Situationen, in denen auch SSH verwendet werden könnte, im Allgemeinen ungünstiger.

Nach dieser Methode müssten Sie Docker und Compose auf dem Host installieren, auf dem Ihre Pipelines ausgeführt werden. Innerhalb Ihres Pipeline-Skripts würden Sie einen Docker-Kontext registrieren und auswählen, der auf Ihren Remote-Produktionshost verweist. Die Verbindungsdetails müssten als Variablen bereitgestellt werden, die im Einstellungsfeld Ihres CI-Anbieters festgelegt sind. Bei ausgewähltem Kontext würden Sie docker-compose up -d ausführen in der Umgebung Ihrer Pipeline, aber sehen Sie sich den Befehl an, der für den Remote-Server ausgeführt wird.

2. Nutzung eines Platform-as-a-Service (PaaS)

Die Übernahme eines Platform-as-a-Service (PaaS)-Angebots ist ein weiterer Ansatz, um Docker-Container in der Produktion auszuführen. Sie können Ihre eigenen mit Lösungen wie Dokku selbst hosten oder ein gehostetes Angebot wie Amazon ECS, DigitalOcean App Platform oder Heroku wählen.

Eine PaaS abstrahiert die Komplexität des Erstellens von Images, der Verwaltung detaillierter Konfigurationen und der Bereitstellung Ihrer eigenen Docker-Hosts. Sie verwenden entweder Git, um Ihr Repository direkt auf die Plattform zu übertragen, oder führen einen CLI-Befehl aus, um Ihre Änderungen hochzuladen. Die PaaS übernimmt die Containererstellung aus Ihren Quell-Assets, Dockerfiles oder plattformspezifischen Konfigurationsdateien.

PaaS-Lösungen sind eine großartige Möglichkeit, mit minimaler manueller Docker-Interaktion schnell online zu gehen. Sie lassen sich einfach in Ihre CI-Pipeline integrieren und die meisten großen Anbieter bieten Beispielskripts an, um Ihnen den Einstieg zu erleichtern. Es ist jedoch möglich, aus einem PaaS herauszuwachsen, was bedeuten könnte, dass Sie Ihre Infrastruktur in Zukunft überdenken müssen.

Die Schritte zum Automatisieren der Bereitstellung auf der von Ihnen gewählten Plattform variieren je nach Anbieter. Wenn Sie Dokku oder ein ähnliches PaaS mit Git-Integration verwenden, könnte Ihr CI-Skript so einfach wie zwei Zeilen sein:

git remote add dokku [email protected]:app-name
git push dokku master

Das Skript fügt Ihren Dokku-Server als Git-Remote hinzu und pusht den Inhalt des Repositorys. Dokku erstellt automatisch ein Image aus Ihrem Dockerfile und Containerinstanzen starten. Sie müssen den öffentlichen SSH-Schlüssel Ihres CI-Servers zu Dokku hinzufügen, damit dies funktioniert; andernfalls wäre Ihr CI-Skript nicht in der Lage, sich bei der Plattform zu authentifizieren.

3. Orchestrierung mit Kubernetes/Docker Swarm

Die Verwendung eines Orchestrators wie Kubernetes oder Docker Swarm ist wohl die häufigste Art, Live-Containerinstanzen auszuführen. Diese Tools wurden speziell entwickelt, um Container in Produktionsumgebungen bereitzustellen und zu skalieren.

Orchestratoren beseitigen die Komplexität des Infrastrukturmanagements, sodass Sie sich auf Ihre Anwendung und ihre Komponenten konzentrieren können. Ähnlich wie Docker Compose verfolgen sie einen deklarativen Ansatz für die Zustandskonfiguration, bei dem Sie definieren, wie der Endzustand aussehen soll. Der Orchestrator bestimmt die richtige Abfolge von Aktionen, um diesen Zustand zu erreichen.

Kubernetes ist der beliebteste Orchestrator. Eine Möglichkeit, mit Kubernetes-Clustern zu interagieren, ist Kubectl, das offizielle CLI-Verwaltungstool. Mit Kubectl können Sie Manifestdateien im YAML-Format anwenden, die die in Ihrem Cluster zu erstellenden Containerressourcen definieren.

Hier ist ein einfaches Manifest, das eine einzelne Containerinstanz erstellt:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: demo
          image: example.com/image:latest

Sie können Kubectl verwenden, um dieses Manifest auf einen Cluster anzuwenden:

kubectl apply -f manifest.yaml

Spätere Änderungen an der Datei werden durch Wiederholen des Befehls übernommen. Kubernetes ergreift automatisch die erforderlichen Maßnahmen, um den neu deklarierten Zustand zu erreichen.

Dies macht Kubernetes zu einer großartigen Option für automatisierte Produktionsbereitstellungen. Sie können kubectl apply verwenden innerhalb Ihrer Pipelines, um die Manifeste in Ihrem Repository zu übernehmen und den deklarierten Zustand auf Ihren Cluster anzuwenden. Durch das Erstellen eines neuen Image-Tags für jeden Commit würde Kubernetes dieses Image abrufen und neue Container für die Bereitstellung starten.

Um dies einzurichten, müssen Sie den Inhalt einer Kubeconfig-Konfigurationsdatei als Pipeline-Variable bereitstellen. Dadurch erhält Kubectl die Anmeldeinformationen für Ihre Clusterverbindung. Die lokale Kubectl-Binärdatei würde dann mit Ihrem Remote-Cluster arbeiten.

Docker Swarm ist eine weitere Orchestrierungsoption, die in Docker integriert ist. Sie können einen Swarm-Stack mit derselben docker-compose.yml einrichten Datei wie zuvor beschrieben. Dann könnten ähnliche Bereitstellungsansätze verwendet werden, entweder eine Verbindung zum Swarm-Host über SSH oder die Verwendung eines Docker-Kontexts, um das Ziel lokaler Docker-Binärdateien zu ändern.

Orchestratoren sind viel komplexer als die Verwendung von einfachem Compose oder einer verwalteten PaaS. Im Fall von Kubernetes müssen Sie neue Abstraktionen, Terminologie und Konfigurationsdateiformate lernen, bevor Sie Ihre Container bereitstellen können. Cluster bieten Ihnen jedoch auch zusätzliche Funktionen, die die langfristige Wartung von Anwendungen erleichtern. Sie können Replikate einfach über mehrere Hosts skalieren, Redundanz einbauen und Protokolle und Metriken aggregieren.

Orchestrierung ist daher die beste Option für größere Systeme, auf denen mehrere Container ausgeführt werden. Das bedeutet nicht, dass die Aufmerksamkeit der Branche, die die Tools erhalten, Sie dazu veranlassen sollte, Kubernetes für jede Bereitstellung zu verwenden. Compose oder ein PaaS sind für kleinere Anwendungsfälle, in denen Sie sich weniger Gedanken über Skalierbarkeit und Anbieterbindung machen, einfacher einzurichten, zu begründen und zu warten.

Zusammenfassung

Wir haben uns drei verschiedene Möglichkeiten angesehen, Container als Produktions-Workloads auszuführen. Die Implementierungsdetails variieren je nach gewählter Strategie, unterstützender Toolchain und CI-Umgebung, daher haben wir auf eine genaue Beschreibung verzichtet, wie Sie die Automatisierung als Teil Ihres Workflows einrichten können. Alle drei können jedoch problemlos in eine CI-Pipeline integriert werden, die jedes Mal ausgeführt wird, wenn Sie Ihren Code zusammenführen oder übertragen.

Die Orchestrierung mit einem Tool wie Kubernetes hat sich schnell zur bevorzugten Methode für skalierbare Bereitstellungen von Systemen entwickelt, auf denen mehrere Container ausgeführt werden. Während es den Betrieb der Dienste, für die es entwickelt wurde, erheblich vereinfachen kann, bringt es auch eine erhebliche Lernkurve und einen erheblichen Wartungsaufwand mit sich, sodass Sie nicht einsteigen sollten, ohne Alternativen in Betracht zu ziehen.

Kleinere Systeme, die aus wenigen Komponenten bestehen, erzielen möglicherweise bessere Ergebnisse, wenn Sie Compose verwenden, um Container mit einer reproduzierbaren Konfiguration auf einem vorhandenen Docker-Host zu starten. Dies bietet einige der Vorteile von Kubernetes, wie z. B. die deklarative Konfiguration, ohne die zusätzliche Komplexität. Sie können sich später in die Orchestrierung einarbeiten, indem Sie Docker Swarm-Unterstützung zu Ihrer vorhandenen Compose-Datei hinzufügen, sodass Sie mehrere verteilte Replikate von Containern starten können.

Schließlich beschleunigen die Platform-as-a-Service-Optionen die Anwendungsbereitstellung, ohne dass Sie über granulare Containerdetails nachdenken müssen. Diese Dienste bieten die Aussicht auf vollständige Infrastrukturautomatisierung bei minimaler Konfiguration. Sie können jedoch langfristig einschränkend sein, also denken Sie darüber nach, wie Ihre Lösung im Laufe der Zeit wachsen wird, bevor Sie sich verpflichten.

Wenn Sie Container in der Produktion bereitstellen, müssen Sie auch das Image-Hosting und die Konfigurationsinjektion in Betracht ziehen. Sie können einen öffentlichen Registrierungsdienst verwenden, um Ihre Images in Ihrer Produktionsumgebung verfügbar zu machen. Alternativ können Sie Ihre eigene private Registrierung ausführen und Anmeldeinformationen als Teil Ihrer CI-Pipeline bereitstellen. Konfigurationswerte werden normalerweise als Umgebungsvariablen bereitgestellt, die Sie im Einstellungsbildschirm Ihres CI-Anbieters definieren können.