Vom Legacy- zum Cloud-Serverless – Teil 1

Hinweis: Dieser Artikel wurde ursprünglich am 4. November 2023 hier veröffentlicht. Es wurde hier erneut veröffentlicht, um ein breiteres Publikum zu erreichen.

Willkommen zum ersten Artikel einer Reihe, die Sie durch den Prozess der Migration einer Legacy-App von lokal in die Cloud führt, mit Schwerpunkt auf Modernisierung, serverlosen Plattformen und integrierten DevOps-Praktiken.

In diesem Artikel konzentrieren wir uns auf die Containerisierung Ihrer App. Wenn Sie jedoch eine App von Grund auf erstellen, ist das vollkommen in Ordnung (eigentlich sogar noch besser). Für dieses Beispiel verwende ich diesen DigitalOcean-Leitfaden, um eine einfache TODO-App mit Python (Flask) und MongoDB als Datenbank zu erstellen. Ich habe einige Anpassungen vorgenommen, damit es besser aussieht, aber der Hauptpunkt besteht darin, etwas zu erstellen, das eine dokumentbasierte NoSQL-Datenbank verwendet, da dies für die bevorstehende Arbeit erforderlich ist.

Sie können das Repository der App hier auf GitHub klonen, wenn Sie noch kein eigenes erstellt haben.

Sobald Sie Ihre App erstellt haben, können wir loslegen!

Docker-Datei

Hier ist die Struktur des Anwendungsverzeichnisses, das wir containerisieren werden, gefolgt von der Docker-Datei.

.
├── app.py
├── LICENSE
├── README.md
├── requirements.txt
├── static
│   └── style.css
└── templates
    └── index.html

Die app.py-Datei ist die Hauptanwendungsdatei, die den Flask-App-Code enthält. Die Datei „requirements.txt“ enthält die Liste der von der Anwendung benötigten Python-Abhängigkeiten. Das Verzeichnis static/ enthält statische Dateien wie CSS, JavaScript und Bilder. Das Verzeichnis templates/ enthält die von der Flask-App verwendeten HTML-Vorlagen.

# Use a minimal base image
FROM python:3.9.7-slim-buster AS base

# Create a non-root user
RUN useradd -m -s /bin/bash flaskuser
USER flaskuser

# Set the working directory
WORKDIR /app

# Copy the requirements file and install dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Add the directory containing the flask command to the PATH
ENV PATH="/home/flaskuser/.local/bin:${PATH}"

# Use a multi-stage build to minimize the size of the image
FROM base AS final

# Copy the app code
COPY app.py .
COPY templates templates/
COPY static static/

# Set environment variables
ENV FLASK_APP=app.py
ENV FLASK_ENV=production

# Expose the port
EXPOSE 5000

# Run the app
CMD ["flask", "run", "--host=0.0.0.0"]

Hier ist eine exemplarische Vorgehensweise und Aufschlüsselung der Docker-Datei:

1. Die Docker-Datei beginnt mit einer FROM-Anweisung, die das zu verwendende Basis-Image angibt. In diesem Fall handelt es sich um python:3.9.7-slim-buster, ein minimales Basisimage, das Python 3.9.7 und einige wichtige Bibliotheken enthält.

2. Die nächste Anweisung erstellt mithilfe der Befehle RUN und useradd einen Nicht-Root-Benutzer namens flaskuser. Dies ist eine bewährte Sicherheitsmethode, um zu vermeiden, dass der Container als Root-Benutzer ausgeführt wird.

3. Die WORKDIR-Anweisung legt das Arbeitsverzeichnis auf /app fest, in das der Anwendungscode kopiert wird.

4. Die COPY-Anweisung kopiert die Datei „requirements.txt“ in das /app-Verzeichnis des Containers.

5. Die RUN-Anweisung installiert die in „requirements.txt“ aufgeführten Abhängigkeiten mithilfe von pip. Die Option --no-cache-dir wird verwendet, um das Zwischenspeichern der heruntergeladenen Pakete zu vermeiden, was dazu beiträgt, die Bildgröße klein zu halten.

6. Die ENV-Anweisung fügt das Verzeichnis, das den flask-Befehl enthält, zur Umgebungsvariablen PATH hinzu. Dies ist erforderlich, um den flask-Befehl später auszuführen.

7. Die FROM-Anweisung startet eine neue Build-Phase unter Verwendung des zuvor definierten Basis-Images. Dies ist ein mehrstufiger Aufbau, der dazu beiträgt, die Größe des endgültigen Bildes zu minimieren.

8. Die COPY-Anweisung kopiert den Anwendungscode (app.py), die Vorlagen (templates/) und die statischen Dateien (static/) in das /app-Verzeichnis des Containers.

9. Die ENV-Anweisung legt die Umgebungsvariablen FLASK_APP und FLASK_ENV fest. FLASK_APP gibt den Namen der Hauptanwendungsdatei an und FLASK_ENV setzt die Umgebung auf Produktion.

10. Die EXPOSE-Anweisung macht Port 5000 verfügbar, der der von Flask verwendete Standardport ist.

11. Die CMD-Anweisung gibt den Befehl an, der beim Start des Containers ausgeführt werden soll. In diesem Fall wird der Befehl flask run mit der Option --host=0.0.0.0 ausgeführt, um eine Bindung an alle Netzwerkschnittstellen herzustellen.

Mit dieser Docker-Datei kann die Anwendung containerisiert und ausgeführt werden. Es ist jedoch wichtig zu beachten, dass unsere App eine Datenbank benötigt, um die während der Ausführung erstellten oder generierten Daten zu speichern. Natürlich könnten Sie ein MongoDB-Datenbank-Image separat abrufen und unabhängig ausführen. Nehmen Sie dann auf beiden Seiten Anpassungen vor, um die Kommunikation zwischen den beiden Containern herzustellen, damit die App Daten erfolgreich in der Datenbank speichern kann. Obwohl dieser Ansatz funktioniert, kann er zeitaufwändig und etwas mühsam sein. Um den Prozess zu optimieren, werden wir stattdessen mit Docker Compose fortfahren. In Docker Compose wird alles in einer YAML-Datei deklariert, und mit dem Befehl docker-compose up können wir die verschiedenen Dienste nahtlos starten und betreiben, was Zeit und Mühe spart.

Optimierte Datenbankintegration mit Docker Compose

Hier ist die grundlegende Docker Compose YAML-Datei, die wir verwenden werden, um den Prozess zu optimieren.

version: '3.9'

services:
  db:
    image: mongo:4.4.14
    ports:
      - "27017:27017"
    volumes:
      - mongo-data:/data/db

  web:
    build: .
    container_name: "myflaskapp"
    ports:
      - "5000:5000"
    environment:
      - MONGO_URI=mongodb://db:27017
    depends_on:
      - db

volumes:
  mongo-data:

Diese Docker Compose YAML-Datei ist für die Einrichtung von zwei Diensten konfiguriert: einer MongoDB-Datenbank (db) und einer Webanwendung (web). Hier ist eine Aufschlüsselung:

• Version: Gibt die Version des verwendeten Docker Compose-Dateiformats an (in diesem Fall 3.9).

• Dienstleistungen:

  • Datenbank (db):

    • Verwendet das MongoDB-Image der Version 4.4.14.
    • Ordnet den Host-Port 27017 dem Container-Port 27017 zu.
    • Verwendet ein Volume namens mongo-data, um MongoDB-Daten dauerhaft zu speichern.

  • Webanwendung (Web):

    • Erstellt das Docker-Image aus dem aktuellen Verzeichnis (.).
    • Legt den Containernamen auf „myflaskapp“ fest.
    • Ordnet den Host-Port 5000 dem Container-Port 5000 zu.
    • Definiert eine Umgebungsvariable MONGO_URI mit dem Wert mongodb://db:27017 und stellt eine Verbindung zum MongoDB-Dienst her.
    • Gibt eine Abhängigkeit vom Datenbankdienst an und stellt sicher, dass die Datenbank vor dem Webdienst gestartet wird.

• Bände:

  • Definiert ein Volume mit dem Namen „mongo-data“ für die Beibehaltung von MongoDB-Daten.

Zusammenfassend lässt sich sagen, dass diese Docker Compose-Datei die Bereitstellung einer MongoDB-Datenbank und einer Flask-Webanwendung orchestriert und sicherstellt, dass sie nahtlos kommunizieren und zusammenarbeiten können.

Navigieren Sie nun zum Verzeichnis mit der Docker Compose-Datei und führen Sie docker-compose up aus, um MongoDB und eine Flask-Webanwendung zu starten. Greifen Sie unter http://localhost:5000 auf die App zu, um sicherzustellen, dass alles wie erwartet funktioniert.

Um anzuhalten, verwenden Sie docker-compose down.

Alles gut? Als nächstes: Migration des Workflows zu Kubernetes im nächsten Artikel.

Das obige ist der detaillierte Inhalt vonVom Legacy- zum Cloud-Serverless – Teil 1. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!