Maison  >  Article  >  développement back-end  >  De l'héritage au cloud sans serveur - Partie 1

De l'héritage au cloud sans serveur - Partie 1

WBOY
WBOYoriginal
2024-09-04 20:30:02827parcourir

Remarque : Cet article a été initialement publié le 4 novembre 2023 ici. Il a été republié ici pour toucher un public plus large.

Bienvenue dans le premier article d'une série qui vous guidera tout au long du processus de migration d'une ancienne application sur site vers le cloud, en mettant l'accent sur la modernisation, les plates-formes sans serveur et les pratiques DevOps intégrées.

Dans cet article, nous nous concentrerons sur la conteneurisation de votre application. Cependant, si vous créez une application à partir de zéro, c'est parfaitement bien (en fait, c'est encore mieux). Pour cet exemple, j'utilise ce guide DigitalOcean pour créer une application TODO simple en utilisant Python (Flask) et MongoDB comme base de données. J'ai fait quelques personnalisations pour le rendre meilleur, mais le point principal est de créer quelque chose qui utilise une base de données basée sur des documents NoSQL, car cela sera nécessaire pour les travaux à venir.

Vous pouvez cloner le référentiel de l'application ici sur GitHub si vous n'avez pas créé le vôtre.

Une fois votre application créée, commençons !

Fichier Docker

Voici la structure du répertoire de l'application que nous allons conteneuriser, suivi du Dockerfile.

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

Le fichier app.py est le fichier d'application principal qui contient le code de l'application Flask. Le fichier Requirements.txt contient la liste des dépendances Python requises par l'application. Le répertoire static/ contient des fichiers statiques tels que CSS, JavaScript et des images. Le répertoire templates/ contient les modèles HTML utilisés par l'application Flask.

# 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"]

Voici une présentation pas à pas et une répartition du Dockerfile :

  1. Le Dockerfile commence par une instruction FROM qui spécifie l'image de base à utiliser. Dans ce cas, il s'agit de python:3.9.7-slim-buster, qui est une image de base minimale qui inclut Python 3.9.7 et quelques bibliothèques essentielles.

  2. L'instruction suivante crée un utilisateur non root nommé flaskuser à l'aide des commandes RUN et useradd. Il s'agit d'une bonne pratique de sécurité pour éviter d'exécuter le conteneur en tant qu'utilisateur root.

  3. L'instruction WORKDIR définit le répertoire de travail sur /app, où le code de l'application sera copié.

  4. L'instruction COPY copie le fichier exigences.txt dans le répertoire /app du conteneur.

  5. L'instruction RUN installe les dépendances répertoriées dans Requirements.txt à l'aide de pip. L'option --no-cache-dir est utilisée pour éviter la mise en cache des packages téléchargés, ce qui permet de conserver une petite taille d'image.

  6. L'instruction ENV ajoute le répertoire contenant la commande flask à la variable d'environnement PATH. Ceci est nécessaire pour exécuter la commande flask plus tard.

  7. L'instruction FROM démarre une nouvelle étape de construction en utilisant l'image de base définie précédemment. Il s'agit d'une construction en plusieurs étapes qui permet de minimiser la taille de l'image finale.

  8. L'instruction COPY copie le code de l'application (app.py), les modèles (templates/) et les fichiers statiques (static/) dans le répertoire /app du conteneur.

  9. L'instruction ENV définit les variables d'environnement FLASK_APP et FLASK_ENV. FLASK_APP spécifie le nom du fichier d'application principal et FLASK_ENV définit l'environnement sur production.

  10. L'instruction EXPOSE expose le port 5000, qui est le port par défaut utilisé par Flask.

  11. L'instruction CMD spécifie la commande à exécuter au démarrage du conteneur. Dans ce cas, il exécute la commande flask run avec l'option --host=0.0.0.0 pour se lier à toutes les interfaces réseau.

Avec ce Dockerfile, l'application peut être conteneurisée et exécutée. Cependant, il est important de noter que notre application nécessite une base de données pour stocker les données créées ou générées pendant son exécution. Bien sûr, vous pouvez extraire séparément une image de base de données MongoDB et l'exécuter indépendamment. Ensuite, effectuez des ajustements des deux côtés pour établir la communication entre les deux conteneurs afin que l'application puisse stocker avec succès les données dans la base de données. Bien que cette approche fonctionne, elle peut prendre du temps et être un peu fastidieuse. Pour rationaliser le processus, nous allons plutôt avancer avec Docker Compose. Dans Docker Compose, tout est déclaré dans un fichier YAML, et en utilisant la commande docker-compose up, nous pouvons démarrer et exploiter les différents services de manière transparente, économisant du temps et des efforts.

Rationalisation de l'intégration de bases de données avec Docker Compose

Voici le fichier YAML Docker Compose de base que nous utiliserons pour rationaliser le processus.

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:

Ce fichier Docker Compose YAML est configuré pour mettre en place deux services : une base de données MongoDB (db) et une application web (web). Voici une répartition :

  • Version : Spécifie la version du format de fichier Docker Compose utilisé (3.9 dans ce cas).

  • Services :

    • Base de données (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.

From legacy to cloud serverless - Part 1

Um anzuhalten, verwenden Sie docker-compose down.

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

From legacy to cloud serverless - Part 1

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn