Bereitstellen einer Django-App: ECs App Runner mit externem Celery

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.

Voraussetzungen

Bevor Sie fortfahren, müssen Sie Folgendes tun:

• Haben Sie ein AWS-Konto
• Einige Django-Kenntnisse haben
• Verstehen Sie, was Warteschlangen, Aufgaben und Makler sind

Was ist Caching und warum wird zwischengespeichert?

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.

Lass uns aufwärmen

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

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

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

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

Vergleich von EC2 und App Runner in diesem Zusammenhang

Architekturen

Sehen wir uns an, wie die App strukturiert ist und wie sich das Bereitstellungssetup verhalten würde.

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

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

Preisvergleichstabelle

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

Einfache Verwaltung

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

Skalierbarkeit

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

Bereitstellungsgeschwindigkeit

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

Anpassung und Kontrolle

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

Sicherheit

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

Projekt-Setup

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.

Abhängigkeiten installieren und Projekte erstellen:

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

Code und Logik

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:

Einrichtung der AWS-Umgebung

Da wir an AWS versenden, müssen wir einige Ressourcen konfigurieren, um

Erstellen einer neuen VPC (Virtual Private Cloud)

Wir schaffen eine isolierte Umgebung und ein Netzwerk für einen sicheren Zugriff und eine sichere Kommunikation zwischen unseren Ressourcen.

Sicherheitsgruppen erstellen

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.

Erstellen des RedisOSS aus ElasticCache

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.

Einrichtung der Elastic Container Registry (ECR).

Die Erstellung eines ECR-Bildes wird sehr einfach und unkompliziert sein.

EINS: Updates zur Bereitstellung des App Runner

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.

Anmeldeinformationen Benutzeranmeldeinformationen

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.

Ergebnisse

Wenn alles fertig ist, haben wir diese Baumstruktur.

Sie können die gesamte Codebasis für dieses Tutorial auf My GitHub haben.

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

Kostenübersicht

• Einrichtung mit dem kostenlosen Kontingent von AWS: Hauptsächlich kostenlos, wenn die Grenzen des kostenlosen Kontingents eingehalten werden. Es können potenzielle Kosten entstehen, wenn die Nutzung die Kontingente des kostenlosen Kontingents übersteigt.
• Einrichtung unter Nutzung aller kostenpflichtigen AWS-Services: Geschätzter Wert: ca. 41,34 $ pro Monat, unter der Annahme eines kontinuierlichen Betriebs einer t2.micro-Instanz für EC2, Elasticache und RDS, mit zusätzlichen Kosten für Datenübertragung und -speicherung.

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.

Analyse

• Selbstverwaltet auf EC2: Dieser Ansatz ist kostengünstig, insbesondere bei Verwendung des kostenlosen AWS-Kontingents. Es erfordert mehr Einrichtung und manuelle Wartung, bietet aber volle Kontrolle über die Umgebung. Ideal für kleinere Projekte oder Projekte mit geringerem Budget.
• Vollständig verwaltete AWS-Services: Dies erhöht zwar die Betriebskosten, verringert jedoch den Arbeitsaufwand im Zusammenhang mit Infrastrukturverwaltung, Skalierung und Wartung. Es eignet sich für größere Anwendungen oder wenn einfache Bedienung und Skalierung Priorität haben.

Zusammenfassung

Neinhhhhhhhhh!!! Leider gibt es hierzu keine Zusammenfassung. Ja, gehen Sie zum besseren Verständnis noch einmal nach oben.

Abschluss

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!