De Docker à Lambda : le parcours d'un administrateur AWS vers les applications Python

Des scripts Python à AWS sans serveur : mon parcours de portefeuille d'investissement

J'ai commencé avec de simples scripts Python pour l'automatisation AWS, évoluant progressivement vers un projet plus complexe. Il y a trois mois, je comprenais à peine les métaclasses ; maintenant, j'ai construit un gestionnaire de portefeuille d'investissement à part entière.

Mon parcours

Des années d'utilisation de Python pour l'automatisation AWS (y compris ce fameux script « fait tout ») m'ont amené à créer une application appropriée. En tirant parti de mes anciens scripts, de Stack Overflow et de l'assistance de Claude en matière d'IA, j'ai enfin compris les principes du développement logiciel.

Capture d'écran de l'application (données de départ, pas investissements réels).

Fatigué des mises à jour manuelles des feuilles de calcul Excel pour mes portefeuilles d'investissement, j'ai automatisé le processus. Cette application Python gère les portefeuilles, suit les transactions, traite les dividendes et met même à jour automatiquement les prix. Au départ, il fonctionnait à merveille dans Docker sur mon serveur domestique (backend Flask, frontend React, base de données SQLite).

L'énigme « Le passe-temps devient un travail »

L'exécuter sur mon serveur domestique me semblait inefficace. En tant que professionnel AWS, gérer des conteneurs sur mon matériel semblait contre-intuitif. La solution semblait évidente : ECS. J'avais déjà le docker-composefichier :

<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>

Cependant, le point de vue d'un architecte AWS (et le calculateur de prix) a suggéré une approche sans serveur :

• Mises à jour quotidiennes des prix et accès peu fréquents suggérés d'éviter les conteneurs 24h/24 et 7j/7.
• Les fichiers frontaux statiques étaient idéaux pour l'hébergement de sites Web S3.
• API Gateway et Lambda géreraient les appels API.
• Aurora Serverless convenait aux données relationnelles.
• DynamoDB pourrait stocker l'historique des prix (même si je n'ai pas atteint ce stade).

Cela m'a conduit dans le terrier du lapin sans serveur. J'avais déjà une expérience sans serveur : un projet de suivi de la température avec ma femme, utilisant des données KNMI et générant un tableau à code couleur pour un projet d'artisanat.

<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>

Ce projet s'est exécuté localement ou via Lambda/API Gateway, en prenant des paramètres de date. La transition vers une application Flask complète avec SQLAlchemy, des tâches en arrière-plan et des relations complexes s'est avérée un défi.

L'attrait sans serveur

Mon application conteneurisée a bien fonctionné, mais l'attrait des services sans serveur était fort. Le potentiel de mise à l’échelle automatique et l’élimination de la gestion des conteneurs étaient tentants.

J'ai donc réorganisé mon application pour un environnement sans serveur. Le projet initial a duré deux mois ; ce serait un jeu d'enfant... du moins c'est ce que je pensais.

La décision relative à la base de données

Les limitations de SQLite avec Lambda m'ont amené à envisager PostgreSQL Aurora Serverless, en maintenant la compatibilité avec mes connaissances SQLAlchemy. J'ai créé un double gestionnaire :

<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>

La courbe d'apprentissage Lambda

La conversion de mon application Flask en fonctions Lambda a été plus complexe que prévu. Ma première tentative a été maladroite :

<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>

Pour améliorer la maintenabilité, j'ai créé un décorateur :

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

Cette structure de fonction Lambda améliorée :

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

Cependant, cela a rompu les routes Flask originales. Un nouveau décorateur permet une double fonctionnalité :

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

Les fonctions de support ont assuré des réponses cohérentes :

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

Cela a permis d'utiliser les mêmes routes pour Flask et Lambda :

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

Simplicité du front-end

Le frontend était simple. L'hébergement de sites Web statiques S3 et CloudFront ont permis un déploiement facile. Un simple script a téléchargé le frontend sur S3 et invalidé le cache CloudFront :

<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>

Le résultat

Après des semaines de travail, mon application était sans serveur. Même si je ne le garderai pas en ligne pour des raisons de sécurité, j'ai appris de précieuses leçons :

1. Les capacités de Python s'étendent au-delà des scripts.
2. L'offre gratuite AWS est inestimable pour le développement.
3. Les CloudWatch Logs sont essentiels pour le débogage.
4. La « bonne » méthode n'est pas toujours la méthode AWS.

Est-ce que je répéterais cela ? Probablement pas. Mais le voyage a été enrichissant, m'apprenant Python et le développement dual-stack. Mon gestionnaire de portefeuille d'investissement fonctionne désormais en toute sécurité sur mon réseau privé.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!