Maison > Article > développement back-end > 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.
Avant de continuer, vous devez :
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.
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 ».
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.
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.
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.
Étudions comment l'application est structurée et comment se comporterait la configuration du déploiement.
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.
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.
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 |
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 |
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 |
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 |
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 |
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 |
É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.
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
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 :
Puisque nous expédions sur AWS, nous devons configurer quelques ressources pour
Nous créons un environnement isolé et un réseau pour un accès et une communication sécurisés entre nos ressources.
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).
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.
La création d'une image ECR sera très simple et directe.
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.
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.
Quand tout est fait, nous avons cette arborescence.
Vous pouvez avoir toute la base de code de ce tutoriel sur My GitHub.
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.
![EC2 1]https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rk8waijxkthu1ule91fn.png)
Alternatively, we can setup the security group separately.
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
This setup is available on GitHub on the dev branch, have a look and open a PR.
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 |
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.
Nahhhhhhhhhh !!! Malheureusement, il n'y a pas de résumé pour celui-ci. Oui, remontez pour mieux comprendre.
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!