Déploiement d'une application Django : ECs App Runner avec céleri externe

Attendez une minute...

Nous avons tous rencontré cette situation où nous sommes occupés à essayer de passer en production, mais de nombreux facteurs entrent en compte dans le choix de votre plateforme de déploiement. Emmmm OUI, nous irons avec AWS. Habituellement, après s'en tenir à une plateforme, nous pouvons désormais nous appuyer sur certains facteurs tels que : l'architecture, le coût, la fiabilité, l'évolutivité, la disponibilité et la faisabilité. Devinez quoi!!! Il ne s'agira pas de fiabilité, d'évolutivité, de disponibilité et de faisabilité puisqu'AWS est fiable pour tout cela. Dans ce tutoriel, nous identifierons les hauts et les bas de certaines architectures pour votre application Django.

Avant de continuer, comprenons quelques prérequis pour parfaitement comprendre ce qui se passe.

:) Tout le code impliqué dans ce tutoriel sera disponible en open source. N'hésitez pas à y mettre votre empreinte.

Conditions préalables

Avant de continuer, vous devez :

• Avoir un compte AWS
• Avoir quelques connaissances en Django
• Comprendre ce que sont la file d'attente, les tâches et les courtiers

Qu'est-ce que la mise en cache et pourquoi mettons-nous en cache

La mise en cache est une technique utilisée pour stocker temporairement les données fréquemment consultées dans un emplacement à accès rapide, réduisant ainsi le temps nécessaire à la récupération de ces données. Dans AWS, la mise en cache améliore les performances et l'évolutivité des applications en minimisant la charge sur les bases de données principales et les API, accélérant ainsi les temps de réponse pour les utilisateurs finaux.

Nous mettons en cache pour améliorer l'efficacité, réduire la latence et réduire les coûts. En stockant les données plus près de l'application, la mise en cache réduit la fréquence des requêtes de base de données, le trafic réseau et la charge de calcul. Cela se traduit par une récupération plus rapide des données, une expérience utilisateur améliorée et une utilisation optimisée des ressources, ce qui est crucial pour les applications à fort trafic.

Réchauffons-nous

1. EC2 :
   Dans leur sens complet, Elastic Compute Engine, EC2 sont des serveurs Web présents dans les centres de données AWS. En d'autres termes, les EC2 sont virtuels et vous pouvez les obtenir auprès d'AWS. Avec toutes les fonctionnalités disponibles, vous pouvez en obtenir un à un tarif mensuel très avantageux dans le cadre d'un « plan par répartition ».

2. AWS App Runner :
   Il s'agit d'un service entièrement géré qui simplifie l'exécution et la mise à l'échelle des applications Web et des API, permettant aux développeurs de déployer rapidement à partir de référentiels de code ou d'images de conteneurs sans gestion de l'infrastructure.

3. Céleri et Céleri Django :
   Celery est une file d'attente de tâches distribuée open source pour le traitement en temps réel en Python. Django Celery intègre Celery au framework Django, permettant l'exécution de tâches asynchrones, les tâches périodiques et la gestion des tâches en arrière-plan dans les applications Django. Le cas d'utilisation de cette technologie varie. Il peut s'agir de services de communication (SMS, e-mails), de tâches planifiées (Crons) et de tâches de traitement de données en arrière-plan, telles que l'agrégation de données, la formation de modèles d'apprentissage automatique ou le traitement de fichiers.

4. Amazon RDS (Service de base de données relationnelle) :
   Il s'agit d'un service de base de données géré qui simplifie la configuration, l'exploitation et la mise à l'échelle des bases de données relationnelles dans le cloud. Il prend en charge divers moteurs de bases de données tels que MySQL, PostgreSQL, Oracle et SQL Server, fournissant des sauvegardes automatisées, des correctifs et une haute disponibilité, libérant ainsi les utilisateurs des tâches d'administration de bases de données.

Comparaison d'EC2 et d'App Runner dans ce contexte

Architectures

Étudions comment l'application est structurée et comment se comporterait la configuration du déploiement.

1. Configuration du déploiement avec AWS App Runner (ECR)
   
   Nous transmettons notre code à GitHub, déclenchant un workflow CodePipeline. CodePipeline utilise CodeBuild pour créer des images Docker stockées dans Elastic Container Registry (ECR) pour la gestion des versions. Ce didacticiel ignore la configuration du Virtual Private Cloud (VPC). Nous garantissons la santé des applications en surveillant constamment les journaux à l'aide de CloudWatch. Et un bonus est la configuration rapide du projet pour utiliser Postgres fourni par AWS RDS et S3 pour les fichiers statiques.

2. Déploiement avec l'instance AWS EC2
   
   En utilisant un processus similaire, en omettant la gestion des versions et l'ECR, nous transférons notre code vers GitHub, déclenchant CodePipeline, qui utilise CodeBuild pour créer des images Docker stockées dans ECR pour la gestion des versions. Les instances EC2 extraient ces images pour déployer l'application dans un VPC, la rendant ainsi accessible aux utilisateurs finaux. L'application interagit avec RDS pour le stockage des données et S3 pour les fichiers statiques, surveillés par CloudWatch. En option, nous pouvons ajouter une configuration SSL dans cette instance avec des options telles que certbot.

Tableau de comparaison des prix

Voici une comparaison de prix hypothétique entre EC2 et App Runner basée sur des scénarios d'utilisation typiques :

Service	Component	Cost Breakdown	Example Monthly Cost (Estimate)
EC2	Instance Usage	t2.micro (1 vCPU, 1 GB RAM)	.50
	Storage	30 GB General Purpose SSD	.00
	Data Transfer	100 GB Data Transfer	.00
	Total		.50
App Runner	Requests	1 million requests	.00
	Compute	1 vCPU, 2 GB RAM, 30 hours/month	.00
	Data Transfer	100 GB Data Transfer	.00
	Total		.00

Facilité de gestion

Faisons un bref résumé de la façon dont se déroule la gestion de ces deux ressources.

Factor	EC2	App Runner
Setup	Manual setup required	Fully managed service
Management Overhead	High - requires OS updates, security patches, etc.	Low - abstracts infrastructure management
Configuration	Extensive control over instance configuration	Limited control, focuses on simplicity

Évolutivité

Factor	EC2	App Runner
Scaling Setup	Manual setup of Auto Scaling groups	Automatic scaling based on traffic
Scaling Management	Requires configuration and monitoring	Managed by AWS, seamless scaling
Flexibility	High - granular control over scaling policies	Simplified, less flexible

Vitesse de déploiement

Factor	EC2	App Runner
Deployment Time	Slower - instance provisioning and configuration	Faster - managed deployment
Update Process	May require downtime or rolling updates	Seamless updates
Automation	Requires setup of deployment pipelines	Simplified, integrated deployment

Personnalisation et contrôle

Factor	EC2	App Runner
Customization	Extensive - full control over environment	Limited - managed environment
Control	High - choose specific instance types, storage, etc.	Lower - focus on ease of use
Flexibility	High - suitable for specialized configurations	Simplified for standard web applications

Sécurité

Factor	EC2	App Runner
Security Control	High - detailed control over security configurations	Simplified security management
Management	Requires manual configuration of security groups, IAM	Managed by AWS, less granular control
Compliance	Extensive options for compliance configurations	Simplified compliance management

Configuration du projet

Étant donné que la comparaison de notre projet ne repose pas sur la configuration du projet elle-même. Nous aurons une application Django de base avec une configuration céleri d'AWS.
Nous partirons d'un projet de base utilisant Django.

Installation des dépendances et création de projets :

Les commandes doivent être exécutées dans l'ordre ci-dessous :

# Project directory creation
mkdir MySchedular && cd MySchedular

# Creating an isolated space for the project dependencies
python -m venv venv && source venv/bin/activate

# Dependencies installation
pip install django celery redis python_dotenv

# Creating project and app
django-admin startproject my_schedular . && python manage.py startapp crons

# Let's add a few files to the project skeleton
touch my_schedular/celery.py crons/urls.py crons/tasks.py

À ce stade, nous pouvons vérifier le squelette de notre projet avec ceci :

tree -I "venv|__pycache__" .

Et nous devrions avoir celui-ci en ce moment

    .
    ├── crons
    │   ├── __init__.py
    │   ├── admin.py
    │   ├── apps.py
    │   ├── migrations
    │   │   └── __init__.py
    │   ├── models.py
+   │   ├── tasks.py
    │   ├── tests.py
+   │   ├── urls.py
    │   └── views.py
    ├── manage.py
    └── my_schedular
        ├── __init__.py
        ├── asgi.py
+       ├── celery.py
        ├── settings.py
        ├── urls.py
        └── wsgi.py

    3 directories, 16 files

Code et logique

Nous pouvons continuer maintenant en ajoutant quelques lignes pour la logique de notre application et en couvrant une autre étape pour ce projet.
1- Mise en place du céleri

# my_schedular/celery.py

from __future__ import absolute_import, unicode_literals
import os
from celery import Celery

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')

app = Celery('myproject')

app.config_from_object('django.conf:settings', namespace='CELERY')

app.autodiscover_tasks()

@app.task(bind=True)
def debug_task(self):
    print(f'Request: {self.request!r}')

2- Écrasons les variables de céleri pour définir notre courtier

# my_schedular/settings.py

CELERY_BROKER_URL = os.getenv('CELERY_BROKER_URL ')
CELERY_RESULT_BACKEND = os.getenv('CELERY_RESULT_BACKEND')

3- Mettez à jour init.py pour vous assurer que l'application est chargée au démarrage de Django :

# my_schedular/__init__.py
from __future__ import absolute_import, unicode_literals

from .celery import app as celery_app

__all__ = ('celery_app',)

4- Nous créons notre tâche

# crons/tasks.py
from celery import shared_task
import time

@shared_task
def add(x, y):
    time.sleep(10)
    return x + y

5- Ajoutons notre vue maintenant, juste une simple avec une simple réponse Json.

# crons/views.py
from django.http import JsonResponse
from crons.tasks import add

def index(request):
    return JsonResponse({"message": "Hello world, your Django App is Running"})

def add_view(request):
    result = add.delay(4, 6)
    return JsonResponse({'task_id': result.id})

6- On ne peut pas avoir de vue, sans endpoint pour permettre d'y accéder

# crons/urls.py
from django.urls import path

from crons.views import add_view, index

urlpatterns = [
    path('', index, name='index'),
    path('add/', add_view, name='add'),
]

7- Ajout des URL de nos applications aux urls.py générales de l'ensemble du projet.

# my_schedular/urls.py
from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path('admin/', admin.site.urls),
    path('/', include('crons.urls')),
]

Ajout de variables d'environnement :

# .env
SECRET_KEY=
DEBUG=
CELERY_BROKER_URL=
CELERY_RESULT_BACKEND=

Après un bon suivi de toutes ces étapes, nous avons ce résultat :

Configuration de l'environnement AWS

Puisque nous expédions sur AWS, nous devons configurer quelques ressources pour

Création d'un nouveau VPC (Virtual Private Cloud)

Nous créons un environnement isolé et un réseau pour un accès et une communication sécurisés entre nos ressources.

Création de groupes de sécurité

Nous créons un groupe de sécurité sous le VPC créé précédemment et ajoutons ensemble des règles entrantes et sortantes au port TCP 6379 (le port Redis).

Création du RedisOSS à partir d'ElasticCache

Fondamentalement, AWS Elastic Cache nous propose deux variétés en matière de mise en cache, à savoir : RedisOSS et memCache. RedisOSS offre des structures de données avancées et des fonctionnalités de persistance, tandis que Memcached est plus simple et se concentre sur la mise en cache à grande vitesse des paires clé-valeur. Redis prend également en charge la réplication et le clustering, contrairement à Memcached. Retour aux affaires, retour à Redis.

Configuration d'Elastic Container Registry (ECR)

La création d'une image ECR sera très simple et directe.

ONE : mises à jour pour déployer App Runner

Suivez les étapes ci-dessous pour que votre programme d'exécution d'application soit exécuté.



Ici, nous devons être très techniques. Un VPC est un réseau sécurisé où se trouvent la plupart de nos ressources, puisqu'aucun exécuteur d'application ne se trouve dans un VPC, nous devrons fournir un moyen sécurisé de communication entre ces ressources.

Informations d'identification de l'utilisateur

Pour ce tutoriel nous aurons besoin d'une autorisation pour connecter notre workflow à notre ECR. Ensuite, nous ajoutons la stratégie d'autorisation AmazonEC2ContainerRegistryFullAccess afin qu'elle puisse transmettre l'image à notre AWS ECR.

Résultats

Quand tout est fait, nous avons cette arborescence.

Vous pouvez avoir toute la base de code de ce tutoriel sur My GitHub.

TWO: Deploying to an EC2

We will go with one the easiest EC2 to setup and the one having a free tier, an ubuntu EC2 instance. And The same code base that was used above is the same we are using here.

Creating an EC2

![EC2 1]https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rk8waijxkthu1ule91fn.png)

Alternatively, we can setup the security group separately.

Setting up the EC2

Run this script to install necessary dependencies

#!/bin/bash

# Update the package list and upgrade existing packages
sudo apt-get update
sudo apt-get upgrade -y

# Install Python3, pip, and other essentials
sudo apt-get install -y python3-pip python3-dev libpq-dev nginx curl

# Install Redis
sudo apt-get install -y redis-server

# Start and enable Redis
sudo systemctl start redis.service
sudo systemctl enable redis.service

# Install Supervisor
sudo apt-get install -y supervisor

# Install virtualenv
sudo pip3 install virtualenv

# Setup your Django project directory (adjust the path as needed)
cd ~/aws-django-redis

# Create a virtual environment
virtualenv venv

# Activate the virtual environment
source venv/bin/activate

# Install Gunicorn and other requirements
pip install gunicorn
pip install -r requirements.txt

# Create directories for logs if they don't already exist
sudo mkdir -p /var/log/aws-django-redis
sudo chown -R ubuntu:ubuntu /var/log/aws-django-redis

# Supervisor Configuration for Gunicorn
echo "[program:aws-django-redis]
command=$(pwd)/venv/bin/gunicorn --workers 3 --bind 0.0.0.0:8000 my_schedular.wsgi:application
directory=$(pwd)
autostart=true
autorestart=true
stderr_logfile=/var/log/aws-django-redis/gunicorn.err.log
stdout_logfile=/var/log/aws-django-redis/gunicorn.out.log
user=ubuntu
" | sudo tee /etc/supervisor/conf.d/aws-django-redis.conf

# Supervisor Configuration for Celery
echo "[program:celery]
command=$(pwd)/venv/bin/celery -A my_schedular worker --loglevel=info
directory=$(pwd)
autostart=true
autorestart=true
stderr_logfile=/var/log/aws-django-redis/celery.err.log
stdout_logfile=/var/log/aws-django-redis/celery.out.log
user=ubuntu
" | sudo tee /etc/supervisor/conf.d/celery.conf

# Reread and update Supervisor
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl restart all

# Set up Nginx to proxy to Gunicorn
echo "server {
    listen 80;
    server_name <your_vm_ip>;

    location / {
        proxy_pass http://127.0.01:8000;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
    }

    error_log  /var/log/nginx/aws-django-redis_error.log;
    access_log /var/log/nginx/aws-django-redis_access.log;
}" | sudo tee /etc/nginx/sites-available/aws-django-redis

# Enable the Nginx site configuration
sudo ln -s /etc/nginx/sites-available/aws-django-redis /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default

# Test Nginx configuration and restart Nginx
sudo nginx -t
sudo systemctl restart nginx

Results

This setup is available on GitHub on the dev branch, have a look and open a PR.

Pricing and Setup Comparison Table

Feature / Service	Self-Managed on EC2 (Free Tier)	Fully Managed AWS Services
EC2 Instance	t2.micro - Free for 750 hrs/mo	Not applicable
Application Hosting	Self-managed Django & Gunicorn	AWS App Runner (automatic scaling)
Database	Self-managed PostgreSQL	Amazon RDS (managed relational DB)
In-Memory Cache	Redis on the same EC2	Amazon ElastiCache (Redis)
Task Queue	Celery with Redis	AWS managed queues (e.g., SQS)
Load Balancer	Nginx (self-setup)	AWS Load Balancer (integrated)
Static Files Storage	Serve via Nginx	Amazon S3 (highly scalable storage)
Log Management	Manual setup (Supervisor, Nginx, Redis)	AWS CloudWatch (logs and monitoring)
Security	Manual configurations	AWS Security Groups, IAM roles
Scaling	Manual scaling	Automatic scaling
Maintenance	Manual updates and patches	Managed by AWS
Pricing	Minimal (mostly within free tier)	Higher due to managed services

Résumé des coûts

• Configuration à l'aide de l'offre gratuite AWS : principalement gratuite si vous restez dans les limites de l'offre gratuite. Des coûts potentiels peuvent survenir si l'utilisation dépasse les allocations du niveau gratuit.
• Configuration à l'aide de tous les services AWS payants : estimé à environ 41,34 $ par mois, en supposant le fonctionnement continu d'une instance t2.micro pour EC2, Elasticache et RDS, avec des coûts supplémentaires pour le transfert et le stockage des données.

Remarque : Les prix sont approximatifs et peuvent varier en fonction de la région et des changements de prix AWS spécifiques. Consultez toujours la page actuelle des tarifs AWS pour obtenir les estimations de coûts les plus précises pour vos besoins spécifiques.

Analyse

• Autogéré sur EC2 : cette approche est rentable, notamment avec l'utilisation du niveau gratuit AWS. Il nécessite plus de configuration et de maintenance manuelle, mais offre un contrôle total sur l'environnement. Idéal pour les projets à plus petite échelle ou à petit budget.
• Services AWS entièrement gérés : bien que cela augmente les coûts opérationnels, cela réduit la charge de travail liée à la gestion, à la mise à l'échelle et à la maintenance de l'infrastructure. Il convient aux applications plus volumineuses ou lorsque la simplicité opérationnelle et l’évolutivité sont des priorités.

Résumé

Nahhhhhhhhhh !!! Malheureusement, il n'y a pas de résumé pour celui-ci. Oui, remontez pour mieux comprendre.

Conclusion

Le chemin d'apprentissage est long et peut sembler difficile, mais une ressource à la fois, l'ajout continu de connaissances nous amène à atteindre nos objectifs et notre but.

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!