Moment mal...
Wir sind alle schon einmal auf diese Situation gestoßen, in der wir damit beschäftigt sind, in die Produktion zu gehen, aber viele Faktoren für die Wahl Ihrer Bereitstellungsplattform verantwortlich sind. Emmmm JA, wir werden uns für AWS entscheiden. Normalerweise können wir uns nach dem Festhalten an einer Plattform nun auf einige Faktoren verlassen, wie zum Beispiel: Architektur, Kosten, Zuverlässigkeit, Skalierbarkeit, Verfügbarkeit und Machbarkeit. Erraten Sie, was!!! Hier wird es nicht um Zuverlässigkeit, Skalierbarkeit, Verfügbarkeit und Machbarkeit gehen, da AWS für all das vertrauenswürdig ist. In diesem Tutorial werden wir die Höhen und Tiefen einiger Architekturen für Ihre Django-App identifizieren.
Bevor wir fortfahren, lassen Sie uns einige Voraussetzungen verstehen, um perfekt zu verstehen, was vor sich geht.
:) Der gesamte in diesem Tutorial enthaltene Code wird als Open Source verfügbar sein. Hinterlassen Sie gerne Ihren Fußabdruck.
Bevor Sie fortfahren, müssen Sie Folgendes tun:
Caching ist eine Technik, mit der häufig aufgerufene Daten vorübergehend an einem Ort mit schnellem Zugriff gespeichert werden, wodurch die Zeit zum Abrufen dieser Daten verkürzt wird. In AWS verbessert Caching die Anwendungsleistung und Skalierbarkeit, indem es die Belastung primärer Datenbanken und APIs minimiert und dadurch die Reaktionszeiten für Endbenutzer beschleunigt.
Wir zwischenspeichern, um die Effizienz zu steigern, die Latenz zu reduzieren und die Kosten zu senken. Durch das Speichern von Daten näher an der Anwendung verringert das Caching die Häufigkeit von Datenbankabfragen, den Netzwerkverkehr und die Rechenlast. Dies führt zu einem schnelleren Datenabruf, einer verbesserten Benutzererfahrung und einer optimierten Ressourcennutzung, was für Anwendungen mit hohem Datenverkehr von entscheidender Bedeutung ist.
EC2:
Im eigentlichen Sinn der Elastic Compute Engine handelt es sich bei EC2 um Webserver, die in AWS-Rechenzentren zu finden sind. Mit anderen Worten: EC2 sind virtuell und können von AWS bezogen werden. Da alle Funktionen verfügbar sind, können Sie diese zu einem sehr günstigen Monatspreis im Rahmen eines „Pay-as-you-go-Plans“ erwerben.
AWS App Runner:
Hierbei handelt es sich um einen vollständig verwalteten Dienst, der die Ausführung und Skalierung von Webanwendungen und APIs vereinfacht und Entwicklern eine schnelle Bereitstellung aus Code-Repositorys oder Container-Images ohne Infrastrukturverwaltung ermöglicht.
Sellerie und Django-Sellerie:
Celery ist eine verteilte Open-Source-Aufgabenwarteschlange für die Echtzeitverarbeitung in Python. Django Celery integriert Celery in das Django-Framework und ermöglicht so die asynchrone Aufgabenausführung, periodische Aufgaben und die Hintergrundjobverwaltung innerhalb von Django-Anwendungen. Der Anwendungsfall dieser Technologie ist unterschiedlich. Dabei kann es sich um Kommunikationsdienste (SMS, E-Mails), geplante Jobs (Crons) und Hintergrunddatenverarbeitungsaufgaben wie Datenaggregation, Modellschulung für maschinelles Lernen oder Dateiverarbeitung handeln.
Amazon RDS (Relational Database Service):
Es handelt sich um einen verwalteten Datenbankdienst, der die Einrichtung, den Betrieb und die Skalierung relationaler Datenbanken in der Cloud vereinfacht. Es unterstützt verschiedene Datenbank-Engines wie MySQL, PostgreSQL, Oracle und SQL Server und bietet automatisierte Backups, Patches und hohe Verfügbarkeit, wodurch Benutzer von Datenbankverwaltungsaufgaben befreit werden.
Sehen wir uns an, wie die App strukturiert ist und wie sich das Bereitstellungssetup verhalten würde.
Bereitstellungseinrichtung mit AWS App Runner (ECR)
Wir pushen unseren Code an GitHub und lösen so einen CodePipeline-Workflow aus. CodePipeline verwendet CodeBuild, um in Elastic Container Registry (ECR) gespeicherte Docker-Images für Versionierungsversionen zu erstellen. In diesem Tutorial wird die Konfiguration der Virtual Private Cloud (VPC) übersprungen. Wir stellen die Anwendungsgesundheit sicher, indem wir die Protokolle mithilfe von CloudWatch ständig überwachen. Und ein Bonus ist die schnelle Konfiguration des Projekts zur Verwendung von Postgres, das von AWS RDS und S3 für statische Dateien bereitgestellt wird.
Bereitstellung mit AWS EC2-Instanz
Mithilfe eines ähnlichen Prozesses, ohne Versionierung und ECR, übertragen wir unseren Code an GitHub und lösen so CodePipeline aus, das CodeBuild verwendet, um in ECR gespeicherte Docker-Images für die Versionierung zu erstellen. EC2-Instanzen rufen diese Images ab, um die Anwendung innerhalb einer VPC bereitzustellen und sie so für Endbenutzer zugänglich zu machen. Die Anwendung interagiert mit RDS für die Datenspeicherung und S3 für statische Dateien, überwacht von CloudWatch. Optional können wir dieser Instanz eine SSL-Konfiguration mit Optionen wie certbot hinzufügen.
Hier ist ein hypothetischer Preisvergleich zwischen EC2 und App Runner basierend auf typischen Nutzungsszenarien:
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 |
Lassen Sie uns kurz zusammenfassen, wie die Verwaltung dieser beiden Ressourcen funktioniert.
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 |
Angesichts der Tatsache, dass der Vergleich unseres Projekts nicht auf dem Projektaufbau selbst beruht. Wir werden eine grundlegende Django-Anwendung mit einer Sellerie-Konfiguration von AWS haben.
Wir werden mit einem Basisprojekt mit Django beginnen.
Die Befehle sollten in der folgenden Reihenfolge ausgeführt werden:
# 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
Zu diesem Zeitpunkt können wir unser Projektgerüst folgendermaßen überprüfen:
tree -I "venv|__pycache__" .
Und das sollten wir im Moment haben
. ├── 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
Wir können jetzt fortfahren, indem wir ein paar Zeilen für die Logik unserer App hinzufügen und einen weiteren Meilenstein für dieses Projekt abdecken.
1- Den Sellerie anrichten
# 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- Überschreiben wir die Sellerie-Variablen, um unseren Broker festzulegen
# my_schedular/settings.py CELERY_BROKER_URL = os.getenv('CELERY_BROKER_URL ') CELERY_RESULT_BACKEND = os.getenv('CELERY_RESULT_BACKEND')
3- Aktualisieren Sie init.py, um sicherzustellen, dass die App geladen wird, wenn Django startet:
# my_schedular/__init__.py from __future__ import absolute_import, unicode_literals from .celery import app as celery_app __all__ = ('celery_app',)
4- Wir erstellen unsere Aufgabe
# crons/tasks.py from celery import shared_task import time @shared_task def add(x, y): time.sleep(10) return x + y
5- Fügen wir jetzt unsere Ansicht hinzu, nur eine einfache mit einer einfachen Json-Antwort.
# 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- Wir können keine Ansicht ohne einen Endpunkt haben, der den Zugriff darauf ermöglicht
# 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- Hinzufügen unserer App-URLs zur allgemeinen URL.py des gesamten Projekts.
# 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')), ]
Umgebungsvariablen hinzufügen:
# .env SECRET_KEY= DEBUG= CELERY_BROKER_URL= CELERY_RESULT_BACKEND=
Nachdem alle diese Schritte ordnungsgemäß durchgeführt wurden, erhalten wir diese Ausgabe:
Da wir an AWS versenden, müssen wir einige Ressourcen konfigurieren, um
Wir schaffen eine isolierte Umgebung und ein Netzwerk für einen sicheren Zugriff und eine sichere Kommunikation zwischen unseren Ressourcen.
Wir erstellen eine Sicherheitsgruppe unter der zuvor erstellten VPC und fügen gemeinsam eingehende und ausgehende Regeln zum TCP-Port 6379 (dem Redis-Port) hinzu.
Grundsätzlich bietet uns AWS Elastic Cache zwei Varianten, wenn es um Caching geht, nämlich: RedisOSS und memCache. RedisOSS bietet erweiterte Datenstrukturen und Persistenzfunktionen, während Memcached einfacher ist und sich auf das Hochgeschwindigkeits-Caching von Schlüssel-Wert-Paaren konzentriert. Redis unterstützt im Gegensatz zu Memcached auch Replikation und Clustering. Zurück zum Geschäft, zurück zu Redis.
Die Erstellung eines ECR-Bildes wird sehr einfach und unkompliziert sein.
Folgen Sie den Schritten unten, um Ihren App-Runner zum Laufen zu bringen.
Hier müssen wir sehr technisch vorgehen. Eine VPC ist ein gesichertes Netzwerk, in dem sich die meisten unserer Ressourcen befinden. Da sich ein App-Runner nicht in einer VPC befindet, müssen wir ein sicheres Mittel für die Kommunikation zwischen diesen Ressourcen bereitstellen.
Für dieses Tutorial benötigen wir eine Autorisierung, um unseren Workflow mit unserem ECR zu verbinden. Dann fügen wir die Berechtigungsrichtlinie AmazonEC2ContainerRegistryFullAccess hinzu, damit das Bild an unseren AWS ECR übertragen werden kann.
Wenn alles fertig ist, haben wir diese Baumstruktur.
Sie können die gesamte Codebasis für dieses Tutorial auf My GitHub haben.
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 |
Hinweis: Die Preise sind Richtwerte und können je nach Region und spezifischen AWS-Preisänderungen variieren. Sehen Sie sich immer die aktuelle AWS-Preisseite an, um die genauesten Kostenschätzungen für Ihre spezifischen Anforderungen zu erhalten.
Neinhhhhhhhhh!!! Leider gibt es hierzu keine Zusammenfassung. Ja, gehen Sie zum besseren Verständnis noch einmal nach oben.
Der Lernweg ist lang und mag schwierig erscheinen, aber eine Ressource nach der anderen und kontinuierliches Anhängen von Wissen führt uns dazu, unsere Ziele und Ziele zu erreichen.
Das obige ist der detaillierte Inhalt vonBereitstellen einer Django-App: ECs App Runner mit externem Celery. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!