Docker-Compose-Workflows zu Kubernetes migrieren

Entdecken Sie, wie Sie Ihre Rails-Entwicklung auf die nächste Stufe heben können: Unsere Anleitung zeigt Ihnen, wie Sie Ihren Docker-Compose-Workflow nahtlos zu Kubernetes migrieren. Von der lokalen Entwicklung bis zur Cloud-Skalierung – erfahren Sie, wie Sie Ihre Anwendung effizient und zuverlässig betreiben können.

Die Containerisierung von Anwendungsbestandteilen ist der erste Schritt beim Bereitstellen und Skalieren von modernen, zustandslosen Anwendungen auf verteilten Plattformen. Wenn Sie Docker Compose in der Entwicklung verwendet haben, haben Sie Ihre Anwendung bereits modernisiert und containerisiert, indem Sie:

• Die notwendigen Konfigurationsinformationen aus Ihrem Code extrahiert haben.
• Den Zustand Ihrer Anwendung ausgelagert haben.
• Ihre Anwendung für die wiederholte Verwendung verpackt haben.

Um Ihre Dienste auf einer verteilten Plattform wie Kubernetes auszuführen, müssen Sie Ihre Compose-Service-Definitionen in Kubernetes-Objekte übersetzen. Hierbei hilft ein Tool namens kompose, das Entwicklern hilft, Compose-Workflows in Container-Orchestrierer wie Kubernetes oder OpenShift zu migrieren.

In diesem Tutorial werden Sie Compose-Services in Kubernetes-Objekte mithilfe von kompose übersetzen. Sie verwenden die von kompose bereitgestellten Objektdefinitionen als Ausgangspunkt und passen sie an, um sicherzustellen, dass Ihr Setup Secrets, Services und PersistentVolumeClaims in der von Kubernetes erwarteten Weise verwendet. Am Ende des Tutorials haben Sie eine Rails-Anwendung mit einer PostgreSQL-Datenbank, die auf einem Kubernetes-Cluster ausgeführt wird. Dieses Setup entspricht der Funktionalität des in Containerizing a Ruby on Rails Application for Development with Docker Compose beschriebenen Codes und ist ein guter Ausgangspunkt für den Aufbau einer produktionsbereiten Lösung, die Ihren Anforderungen entspricht.

Voraussetzungen

• Ein Kubernetes 1.19+ Cluster mit aktivierter rollenbasierter Zugriffssteuerung (RBAC).
• Das kubectl-Befehlszeilentool auf Ihrem lokalen Rechner oder Entwicklungsserver installiert und konfiguriert, um sich mit Ihrem Cluster zu verbinden.
• Docker auf Ihrem lokalen Rechner oder Entwicklungsserver installiert.
• Ein Docker Hub-Konto.

Schritt 1 — Installation von kompose

Um mit kompose zu beginnen, navigieren Sie zur GitHub Releases-Seite des Projekts und kopieren Sie den Link zur aktuellen Version. Laden Sie dann die neueste Version von kompose herunter und machen Sie sie ausführbar.

curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-linux-amd64 -o kompose

chmod +x kompose

sudo mv ./kompose /usr/local/bin/kompose

kompose version

Schritt 2 — Klonen und Verpacken der Anwendung

Klonen Sie das Projektcode und erstellen Sie das Anwendungsimage, das Sie später auf Ihrem Kubernetes-Cluster ausführen können.

git clone https://github.com/do-community/rails-sidekiq.git rails_project

cd rails_project

git checkout compose-workflow

docker build -t your_dockerhub_user/rails-kubernetes .

docker push your_dockerhub_user/rails-kubernetes

Schritt 3 — Übersetzen von Compose-Services in Kubernetes-Objekte mit kompose

Verwenden Sie kompose, um Ihre Compose-Service-Definitionen in Kubernetes-Objekte umzuwandeln. Passen Sie die generierten YAML-Dateien an Ihre Anforderungen an.

kompose convert

mkdir k8s-manifests

mv *.yaml k8s-manifests

cd k8s-manifests

Schritt 4 — Erstellen von Kubernetes-Secrets

Erstellen Sie Secrets für Ihren Datenbankbenutzer und Ihr Passwort und fügen Sie sie Ihren Anwendungs- und Datenbankbereitstellungen hinzu.

echo -n ‚your_database_name‘ | base64

echo -n ‚your_database_username‘ | base64

echo -n ‚your_database_password‘ | base64

nano secret.yaml

Fügen Sie den folgenden Code in die `secret.yaml` ein:

apiVersion: v1

kind: Secret

metadata:

name: database-secret

data:

DATABASE_NAME: your_database_name

DATABASE_PASSWORD: your_encoded_password

DATABASE_USER: your_encoded_username

POSTGRES_DB: your_database_name

POSTGRES_PASSWORD: your_encoded_password

POSTGRES_USER: your_encoded_username

Speichern und schließen Sie die Datei.

Schritt 5 — Anpassung des PersistentVolumeClaim und Freigabe des Anwendungs-Frontends

Bevor wir unsere Anwendung ausführen, werden wir zwei letzte Änderungen vornehmen, um sicherzustellen, dass unser Datenbank-Speicher ordnungsgemäß bereitgestellt wird und dass wir unser Anwendungs-Frontend mithilfe eines Load Balancers freigeben können.

Zuerst werden wir die Speicherressource in dem PersistentVolumeClaim, den kompose für uns erstellt hat, modifizieren. Dieser Claim ermöglicht es uns, Speicher dynamisch zu provisionieren, um den Zustand unserer Anwendung zu verwalten.

Um mit PersistentVolumeClaims zu arbeiten, muss eine StorageClass erstellt und konfiguriert werden, um Speicherressourcen bereitzustellen. In unserem Fall, da wir mit centron Kubernetes arbeiten, ist unser Standard-StorageClass-Provisionierer auf dobs.csi.centron.de – centron Block Storage eingestellt.

Wir können dies überprüfen, indem wir Folgendes eingeben:

kubectl get storageclass

Wenn Sie mit einem centron-Cluster arbeiten, sehen Sie die folgende Ausgabe:

NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE

do-block-storage (default) dobs.csi.centron.de Delete Immediate true 76m

Wenn Sie nicht mit einem centron-Cluster arbeiten, müssen Sie eine StorageClass erstellen und einen Provisionierer Ihrer Wahl konfigurieren. Für Details dazu, wie dies zu tun ist, lesen Sie bitte die offizielle Dokumentation.

Als kompose die Datei db-data-persistentvolumeclaim.yaml erstellt hat, hat es die Speicherressource auf eine Größe gesetzt, die die minimalen Größenanforderungen unseres Provisionierers nicht erfüllt. Daher müssen wir unseren PersistentVolumeClaim ändern, um die minimal mögliche centron Block Storage-Einheit zu verwenden: 1 GB. Bitte passen Sie dies nach Bedarf an Ihre Speicheranforderungen an.

Öffnen Sie db-data-persistentvolumeclaim.yaml:

nano db-data-persistentvolumeclaim.yaml

Ersetzen Sie den Speicherwert durch 1Gi:

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

creationTimestamp: null

labels:

io.kompose.service: db-data

name: db-data

spec:

accessModes:

– ReadWriteOnce

resources:

requests:

storage: 1Gi

status: {}

Beachten Sie auch, dass `accessMode: ReadWriteOnce` bedeutet, dass das als Ergebnis dieses Claims bereitgestellte Volume von einem einzelnen Knoten nur lesend und schreibend ist. Bitte sehen Sie sich die Dokumentation für weitere Informationen zu verschiedenen Zugriffsmodi an.

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Als Nächstes öffnen Sie app-service.yaml:

nano app-service.yaml

Wir werden diesen Service extern freigeben, indem wir einen centron Load Balancer verwenden. Wenn Sie keinen centron-Cluster verwenden, lesen Sie bitte die entsprechende Dokumentation Ihres Cloud-Anbieters zu deren Load Balancern. Alternativ können Sie die offizielle Kubernetes-Dokumentation zur Einrichtung eines hochverfügbaren Clusters mit kubeadm verwenden, in diesem Fall können Sie jedoch keine PersistentVolumeClaims zur Bereitstellung von Speicher verwenden.

Spezifizieren Sie innerhalb der Service-Spezifikation LoadBalancer als den Servicetyp:

apiVersion: v1

kind: Service

. . .

spec:

type: LoadBalancer

ports:

. . .

Wenn wir den App-Service erstellen, wird automatisch ein Load Balancer erstellt, der uns eine externe IP zur Verfügung stellt, über die wir auf unsere Anwendung zugreifen können.

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Mit allen unseren Dateien an Ort und Stelle sind wir bereit, die Anwendung zu starten und zu testen.

Anmerkung: Wenn Sie Ihre bearbeiteten Kubernetes-Manifeste mit einem Satz von Referenzdateien vergleichen möchten, um sicherzustellen, dass Ihre Änderungen diesem Tutorial entsprechen, enthält das begleitende Github-Repository einen Satz von getesteten Manifesten. Sie können jede Datei einzeln vergleichen, oder Sie können auch Ihren lokalen Git-Zweig wechseln, um den kubernetes-workflow-Zweig zu verwenden.

Wenn Sie sich für den Wechsel von Branches entscheiden, stellen Sie sicher, dass Sie Ihre secrets.yaml-Datei in die neu ausgecheckte Version kopieren, da wir sie früher im Tutorial zu .gitignore hinzugefügt haben. Docker-Compose-Workflows zu Kubernetes migrieren