Von Docker zu Lambda: Die Reise eines AWS-Administrators in Python-Anwendungen

Von Python-Skripten zu serverlosem AWS: Meine Investment-Portfolio-Reise

Ich begann mit einfachen Python-Skripten für die AWS-Automatisierung und entwickelte mich nach und nach zu einem komplexeren Projekt. Vor drei Monaten verstand ich Metaklassen kaum; Jetzt habe ich einen vollwertigen Anlageportfoliomanager aufgebaut.

Meine Reise

Die jahrelange Verwendung von Python für die AWS-Automatisierung (einschließlich des berüchtigten „Alles-macht“-Skripts) hat mich dazu gebracht, eine richtige Anwendung zu erstellen. Durch die Nutzung meiner früheren Skripte, Stack Overflow und Claudes KI-Unterstützung habe ich endlich die Prinzipien der Softwareentwicklung verstanden.

App-Screenshot (Startdaten, keine tatsächlichen Investitionen).

Ich hatte keine Lust mehr auf manuelle Excel-Tabellenaktualisierungen für meine Anlageportfolios und habe den Prozess automatisiert. Diese Python-Anwendung verwaltet Portfolios, verfolgt Transaktionen, verarbeitet Dividenden und aktualisiert sogar Preise automatisch. Anfangs lief es wunderbar in Docker auf meinem Heimserver (Flask-Backend, React-Frontend, SQLite-Datenbank).

Das Rätsel „Hobby wird zum Job“

Die Ausführung auf meinem Heimserver fühlte sich ineffizient an. Als AWS-Experte erschien mir die Verwaltung von Containern auf meiner Hardware kontraintuitiv. Die Lösung schien offensichtlich: ECS. Ich hatte bereits die docker-compose-Datei:

<code>services:
  backend:
    build: ./backend
    container_name: investment-portfolio-backend
    environment:
      - DB_DIR=/data/db
      - LOG_DIR=/data/logs
      - DOMAIN=${DOMAIN:-localhost}
    volumes:
      - /path/to/your/data:/data
    networks:
      - app-network

  frontend:
    build:
      context: ./frontend
      args:
        - DOMAIN=${DOMAIN:-localhost}
        - USE_HTTPS=${USE_HTTPS:-false}
    container_name: investment-portfolio-frontend
    environment:
      - DOMAIN=${DOMAIN:-localhost}
      - USE_HTTPS=${USE_HTTPS:-false}
    ports:
      - "80:80"
    depends_on:
      - backend
    networks:
      - app-network</code>

Die Sichtweise eines AWS-Architekten (und der Preisrechner) deuteten jedoch auf einen serverlosen Ansatz hin:

• Tägliche Preisaktualisierungen und seltener Zugriff empfehlen, 24/7-Container zu vermeiden.
• Statische Frontend-Dateien waren ideal für das S3-Website-Hosting.
• API Gateway und Lambda würden API-Aufrufe verarbeiten.
• Aurora Serverless eignete sich für die relationalen Daten.
• DynamoDB konnte den Preisverlauf speichern (obwohl ich dieses Stadium noch nicht erreicht habe).

Das führte mich in das serverlose Kaninchenloch. Ich hatte bereits Erfahrung ohne Server – ein Temperaturverfolgungsprojekt mit meiner Frau, bei dem ich KNMI-Daten verwendete und eine farbcodierte Tabelle für ein Bastelprojekt erstellte.

<code>| Date       | Min.Temp | Min.Kleur   | Max.Temp | Max.Kleur   |
----------------------------------------------------------------
| 2023-03-01 |   -4.1°C | darkblue   |    7.1°C | lightblue  |
| 2023-03-02 |    1.3°C | blue       |    6.8°C | lightblue  |
...</code>

Dieses Projekt lief lokal oder über Lambda/API Gateway unter Verwendung von Datumsparametern. Die Skalierung auf eine vollständige Flask-Anwendung mit SQLAlchemy, Hintergrundjobs und komplexen Beziehungen erwies sich als Herausforderung.

Der serverlose Reiz

Meine Containeranwendung funktionierte gut, aber die Anziehungskraft serverloser Dienste war groß. Das Potenzial für automatische Skalierung und die Eliminierung der Containerverwaltung waren verlockend.

Also habe ich meine Anwendung für eine serverlose Umgebung umgestaltet. Das ursprüngliche Projekt dauerte zwei Monate; Das wäre ein Kinderspiel... zumindest dachte ich das.

Die Datenbankentscheidung

Die Einschränkungen von SQLite mit Lambda veranlassten mich, PostgreSQL Aurora Serverless in Betracht zu ziehen, um die Kompatibilität mit meinen SQLAlchemy-Kenntnissen aufrechtzuerhalten. Ich habe einen Dual-Handler erstellt:

<code>services:
  backend:
    build: ./backend
    container_name: investment-portfolio-backend
    environment:
      - DB_DIR=/data/db
      - LOG_DIR=/data/logs
      - DOMAIN=${DOMAIN:-localhost}
    volumes:
      - /path/to/your/data:/data
    networks:
      - app-network

  frontend:
    build:
      context: ./frontend
      args:
        - DOMAIN=${DOMAIN:-localhost}
        - USE_HTTPS=${USE_HTTPS:-false}
    container_name: investment-portfolio-frontend
    environment:
      - DOMAIN=${DOMAIN:-localhost}
      - USE_HTTPS=${USE_HTTPS:-false}
    ports:
      - "80:80"
    depends_on:
      - backend
    networks:
      - app-network</code>

Die Lambda-Lernkurve

Die Konvertierung meiner Flask-Anwendung in Lambda-Funktionen war komplexer als erwartet. Mein erster Versuch war ungeschickt:

<code>| Date       | Min.Temp | Min.Kleur   | Max.Temp | Max.Kleur   |
----------------------------------------------------------------
| 2023-03-01 |   -4.1°C | darkblue   |    7.1°C | lightblue  |
| 2023-03-02 |    1.3°C | blue       |    6.8°C | lightblue  |
...</code>

Um die Wartbarkeit zu verbessern, habe ich einen Dekorator erstellt:

<code>@contextmanager
def db_session():
    # ... (code for environment-aware database session management) ...</code>

Diese verbesserte Lambda-Funktionsstruktur:

<code># ... (initial, inefficient Lambda handler code) ...</code>

Dadurch wurden jedoch die ursprünglichen Flask-Routen unterbrochen. Ein neuer Dekorator ermöglichte eine doppelte Funktionalität:

<code>def lambda_response(func):
    # ... (decorator for cleaner Lambda responses) ...</code>

Unterstützende Funktionen stellten konsistente Antworten sicher:

<code>@lambda_response
def get_portfolios(event, context):
    # ... (simplified Lambda function) ...</code>

Dies ermöglichte die Verwendung derselben Routen für Flask und Lambda:

<code>def dual_handler(route_path, methods=None):
    # ... (decorator for both Flask routes and Lambda handlers) ...</code>

Frontend-Einfachheit

Das Frontend war unkompliziert. Das statische S3-Website-Hosting und CloudFront sorgten für eine einfache Bereitstellung. Ein einfaches Skript hat das Frontend auf S3 hochgeladen und den CloudFront-Cache ungültig gemacht:

<code>def create_lambda_response(flask_response):
    # ... (function to convert Flask response to Lambda response format) ...

def create_flask_request(event):
    # ... (function to convert Lambda event to Flask request) ...</code>

Das Ergebnis

Nach wochenlanger Arbeit war meine Anwendung serverlos. Obwohl ich es aus Sicherheitsgründen nicht online halte, habe ich wertvolle Lektionen gelernt:

1. Pythons Fähigkeiten gehen über die Skripterstellung hinaus.
2. Das kostenlose AWS-Kontingent ist für die Entwicklung von unschätzbarem Wert.
3. CloudWatch-Protokolle sind für das Debuggen unerlässlich.
4. Der „richtige“ Weg ist nicht immer der AWS-Weg.

Würde ich das wiederholen? Wahrscheinlich nicht. Aber die Reise hat sich gelohnt und mir etwas über Python und die Dual-Stack-Entwicklung beigebracht. Mein Anlageportfoliomanager läuft jetzt sicher in meinem privaten Netzwerk.

Das obige ist der detaillierte Inhalt vonVon Docker zu Lambda: Die Reise eines AWS-Administrators in Python-Anwendungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!