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

王林
Freigeben: 2024-08-08 22:54:12
Original
1287 Leute haben es durchsucht

Moment mal...

Deploying A Django App: ECs App Runner with External Celery

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

Deploying A Django App: ECs App Runner with External Celery

  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)
    Deploying A Django App: ECs App Runner with External Celery
    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
    Deploying A Django App: ECs App Runner with External Celery
    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
Nach dem Login kopieren

Zu diesem Zeitpunkt können wir unser Projektgerüst folgendermaßen überprüfen:

tree -I "venv|__pycache__" .
Nach dem Login kopieren

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
Nach dem Login kopieren

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}')
Nach dem Login kopieren

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')
Nach dem Login kopieren

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',)
Nach dem Login kopieren

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
Nach dem Login kopieren

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})
Nach dem Login kopieren

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'),
]
Nach dem Login kopieren

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')),
]
Nach dem Login kopieren

Umgebungsvariablen hinzufügen:

# .env
SECRET_KEY=
DEBUG=
CELERY_BROKER_URL=
CELERY_RESULT_BACKEND=
Nach dem Login kopieren

Nachdem alle diese Schritte ordnungsgemäß durchgeführt wurden, erhalten wir diese Ausgabe:
Deploying A Django App: ECs App Runner with External Celery

Einrichtung der AWS-Umgebung

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

Erstellen einer neuen VPC (Virtual Private Cloud)

Deploying A Django App: ECs App Runner with External Celery
Wir schaffen eine isolierte Umgebung und ein Netzwerk für einen sicheren Zugriff und eine sichere Kommunikation zwischen unseren Ressourcen.

Sicherheitsgruppen erstellen

Deploying A Django App: ECs App Runner with External Celery
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

Deploying A Django App: ECs App Runner with External Celery

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

Deploying A Django App: ECs App Runner with External Celery
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.
Deploying A Django App: ECs App Runner with External Celery
Deploying A Django App: ECs App Runner with External Celery
Deploying A Django App: ECs App Runner with External Celery
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.
Deploying A Django App: ECs App Runner with External Celery

Ergebnisse

Wenn alles fertig ist, haben wir diese Baumstruktur.
Deploying A Django App: ECs App Runner with External Celery

Deploying A Django App: ECs App Runner with External Celery

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)
Deploying A Django App: ECs App Runner with External Celery
Alternatively, we can setup the security group separately.
Deploying A Django App: ECs App Runner with External Celery
Deploying A Django App: ECs App Runner with External Celery
Deploying A Django App: ECs App Runner with External Celery
Deploying A Django App: ECs App Runner with External Celery

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
Nach dem Login kopieren

Results

This setup is available on GitHub on the dev branch, have a look and open a PR.
Deploying A Django App: ECs App Runner with External Celery
Deploying A Django App: ECs App Runner with External Celery

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!

Quelle:dev.to
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage
Über uns Haftungsausschluss Sitemap
Chinesische PHP-Website:Online-PHP-Schulung für das Gemeinwohl,Helfen Sie PHP-Lernenden, sich schnell weiterzuentwickeln!