Menggunakan Apl Django: ECs App Runner dengan Saderi Luaran

Tunggu sebentar...

Kami semua telah menghadapi situasi ini di mana kami sibuk mencuba untuk pergi ke pengeluaran, tetapi banyak faktor menyumbang untuk pilihan platform penggunaan anda. Emmmm YA, kami akan pergi dengan AWS. Biasanya selepas berpegang pada platform, kita kini boleh bergantung pada beberapa faktor seperti: seni bina, kos, kebolehpercayaan, skalabiliti, ketersediaan dan kebolehlaksanaan. Cuba teka!!! Ini bukan tentang kebolehpercayaan, skalabiliti, ketersediaan dan kebolehlaksanaan kerana AWS dipercayai untuk semua itu. Dalam tutorial ini, kami akan mengenal pasti pasang surut beberapa seni bina untuk Apl Django anda.

Sebelum kita meneruskan, mari kita fahami beberapa prasyarat untuk memahami dengan sempurna apa yang sedang berlaku.

:) Semua kod yang terlibat dalam tutorial ini akan tersedia sebagai sumber terbuka. Jangan ragu untuk meletakkan jejak anda ke dalamnya.

Prasyarat

Sebelum bergerak ke hadapan, anda dikehendaki:

• Mempunyai akaun AWS
• Mempunyai sedikit pengetahuan Django
• Fahami apa itu beratur, tugas, broker

Apakah Caching dan Mengapa kita Cache

Caching ialah teknik yang digunakan untuk menyimpan data yang kerap diakses buat sementara waktu di lokasi akses pantas, mengurangkan masa yang diambil untuk mendapatkan semula data ini. Dalam AWS, caching meningkatkan prestasi aplikasi dan kebolehskalaan dengan meminimumkan beban pada pangkalan data utama dan API, dengan itu mempercepatkan masa tindak balas untuk pengguna akhir.

Kami cache untuk meningkatkan kecekapan, mengurangkan kependaman dan mengurangkan kos. Dengan menyimpan data lebih dekat dengan aplikasi, caching mengurangkan kekerapan pertanyaan pangkalan data, trafik rangkaian dan beban pengiraan. Ini menghasilkan perolehan data yang lebih pantas, pengalaman pengguna yang lebih baik dan penggunaan sumber yang dioptimumkan, yang penting untuk aplikasi trafik tinggi.

Jom memanaskan badan

1. EC2:
   Daripada maksud penuh Enjin Pengiraan Elastik, EC2 ialah pelayan web yang terdapat dalam pusat data AWS. Dalam erti kata lain, EC2 adalah maya yang boleh anda perolehi daripada AWS. Dengan semua fungsi yang tersedia, anda boleh mendapatkannya pada kadar bulanan yang sangat murah di bawah "pelan bayar semasa anda pergi".

2. AWS App Runner:
   Ini ialah perkhidmatan terurus sepenuhnya yang memudahkan menjalankan dan menskalakan aplikasi web dan API, membolehkan pembangun menggunakan dengan cepat daripada repositori kod atau imej bekas tanpa pengurusan infrastruktur.

3. Saderi dan Django Saderi:
   Saderi ialah baris gilir tugas teragih sumber terbuka untuk pemprosesan masa nyata dalam Python. Django Celery menyepadukan Celery dengan rangka kerja Django, membolehkan pelaksanaan tugas tak segerak, tugas berkala dan pengurusan kerja latar belakang dalam aplikasi Django. Kes penggunaan teknologi ini berbeza-beza. Ia boleh menjadi perkhidmatan komunikasi (SMS, e-mel), Kerja Berjadual (Crons) dan tugas pemprosesan data latar belakang, seperti pengagregatan data, latihan model pembelajaran mesin atau pemprosesan fail.

4. Amazon RDS (Perkhidmatan Pangkalan Data Perhubungan):
   Ia ialah perkhidmatan pangkalan data terurus yang memudahkan penyediaan, pengendalian dan penskalaan pangkalan data hubungan dalam awan. Ia menyokong pelbagai enjin pangkalan data seperti MySQL, PostgreSQL, Oracle dan SQL Server, menyediakan sandaran automatik, menampal dan ketersediaan tinggi, membebaskan pengguna daripada tugas pentadbiran pangkalan data.

Membandingkan EC2 dan App Runner dalam konteks ini

Seni bina

Mari kita kaji cara apl itu distrukturkan dan cara persediaan pelaksanaan akan bertindak.

1. Persediaan penggunaan dengan AWS App Runner (ECR)
   
   Kami menolak kod kami ke GitHub, mencetuskan aliran kerja CodePipeline. CodePipeline menggunakan CodeBuild untuk mencipta imej Docker yang disimpan dalam Elastic Container Registry (ECR) untuk keluaran versi. Tutorial ini melangkau konfigurasi Virtual Private Cloud (VPC). Kami memastikan kesihatan aplikasi dengan sentiasa memantau log menggunakan CloudWatch. Dan bonus ialah konfigurasi pantas projek untuk menggunakan Postgres yang disediakan oleh AWS RDS dan S3 untuk fail statik.

2. Pengedaran dengan Instance AWS EC2
   
   Menggunakan proses yang serupa, mengenepikan versi dan ECR, kami menolak kod kami ke GitHub, mencetuskan CodePipeline, yang menggunakan CodeBuild untuk mencipta imej Docker yang disimpan dalam ECR untuk versi. Kejadian EC2 menarik imej ini untuk menggunakan aplikasi dalam VPC, menjadikannya boleh diakses oleh pengguna akhir. Aplikasi ini berinteraksi dengan RDS untuk penyimpanan data dan S3 untuk fail statik, dipantau oleh CloudWatch. Secara pilihan, kami boleh menambah konfigurasi SSL ke dalam contoh ini dengan pilihan seperti certbot.

Jadual Perbandingan Harga

Berikut ialah perbandingan harga hipotesis antara EC2 dan App Runner berdasarkan senario penggunaan biasa:

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

Kemudahan Pengurusan

Mari kita dapatkan ringkasan ringkas tentang cara menguruskan kedua-dua sumber ini.

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

Kebolehskalaan

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

Kelajuan Penggunaan

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

Penyesuaian dan Kawalan

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

Keselamatan

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

Persediaan Projek

Memandangkan perbandingan projek kami tidak bergantung pada persediaan projek itu sendiri. Kami akan mempunyai aplikasi Django asas dengan konfigurasi saderi daripada AWS.
Kami akan menggunakan projek asas menggunakan Django.

Memasang Ketergantungan dan Penciptaan Projek:

Arahan hendaklah dijalankan mengikut susunan di bawah:

# 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

Pada masa ini kami boleh menyemak rangka projek kami dengan ini:

tree -I "venv|__pycache__" .

Dan kita sepatutnya mempunyai yang ini pada masa ini

    .
    ├── 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

Kod dan Logik

Kita boleh meneruskan sekarang dengan menambahkan beberapa baris untuk logik apl keluar dan merangkumi satu lagi peristiwa penting untuk projek ini.
1- Sediakan saderi

# 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- Mari tulis ganti pembolehubah saderi untuk menetapkan broker kami

# my_schedular/settings.py

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

3- Kemas kini init.py untuk memastikan apl dimuatkan apabila Django bermula:

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

from .celery import app as celery_app

__all__ = ('celery_app',)

4- Kami mencipta tugas kami

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

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

5- Mari tambahkan pandangan kami sekarang, hanya paparan ringkas dengan respons Json yang mudah.

# 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- Kami tidak boleh mempunyai pandangan, tanpa titik akhir untuk membolehkannya mengaksesnya

# 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- Menambah url apl kami pada urls.py umum keseluruhan projek.

# 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')),
]

Menambah Pembolehubah Persekitaran:

# .env
SECRET_KEY=
DEBUG=
CELERY_BROKER_URL=
CELERY_RESULT_BACKEND=

Selepas susulan semua langkah ini dengan betul, kami mempunyai output ini:

Persediaan Persekitaran AWS

Memandangkan kami menghantar ke AWS Kami perlu mengkonfigurasi beberapa sumber untuk

Mencipta VPC baharu (Awan Persendirian Maya)

Kami mencipta persekitaran terpencil dan rangkaian untuk akses dan komunikasi yang selamat antara sumber kami.

Mencipta Kumpulan Keselamatan

Kami mencipta kumpulan keselamatan di bawah VPC yang dibuat sebelum ini dan bersama-sama menambah peraturan masuk dan keluar pada port TCP 6379 (Port Redis).

Mencipta RedisOSS daripada ElasticCache

Pada asasnya, AWS Elastic Cache menawarkan kepada kita dua jenis dalam hal caching, iaitu: RedisOSS dan memCache. RedisOSS menawarkan struktur data lanjutan dan ciri kegigihan, manakala Memcached lebih ringkas, memfokuskan pada caching berkelajuan tinggi pasangan nilai kunci. Redis juga menyokong replikasi dan pengelompokan, tidak seperti Memcached. Kembali ke perniagaan, kembali ke Redis.

Persediaan Pendaftaran Bekas Elastik (ECR).

Penciptaan imej ECR akan menjadi sangat mudah dan lurus ke hadapan.

SATU: Kemas kini untuk menggunakan App Runner

Ikuti langkah di bawah untuk membolehkan pelari apl anda berjalan.



Di sini kita perlu sangat teknikal. VPC ialah rangkaian terjamin di mana kebanyakan sumber kami terletak, memandangkan pelari Apl tidak ditemui dalam VPC, kami perlu menyediakan cara selamat untuk komunikasi antara sumber tersebut.

Tauliah kelayakan pengguna

Untuk tutorial ini, kami memerlukan kebenaran untuk menyambung aliran kerja kami ke ECR kami. Kemudian kami menambah dasar kebenaran AmazonEC2ContainerRegistryFullAccess supaya ia boleh menolak imej ke AWS ECR kami.

Keputusan

Apabila semuanya selesai, kami mempunyai struktur pokok ini.

Anda boleh memiliki pangkalan kod keseluruhan untuk tutorial ini di GitHub Saya.

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

Ringkasan Kos

• Persediaan Menggunakan Peringkat Percuma AWS: Terutamanya percuma jika kekal dalam had peringkat percuma. Potensi kos mungkin timbul jika penggunaan melebihi elaun peringkat percuma.
• Persediaan Menggunakan Semua Perkhidmatan AWS Berbayar: Dianggarkan sekitar $41.34 sebulan, dengan mengandaikan operasi berterusan satu contoh t2.micro untuk EC2, Elasticache dan RDS, dengan kos tambahan untuk pemindahan dan penyimpanan data.

Nota: Harga adalah anggaran dan boleh berbeza-beza berdasarkan rantau dan perubahan harga AWS tertentu. Sentiasa semak halaman Harga AWS semasa untuk mendapatkan anggaran kos yang paling tepat untuk keperluan khusus anda.

Analisis

• Diurus Sendiri pada EC2: Pendekatan ini menjimatkan kos, terutamanya dengan penggunaan peringkat percuma AWS. Ia memerlukan lebih banyak persediaan dan penyelenggaraan manual tetapi menyediakan kawalan penuh ke atas alam sekitar. Sesuai untuk projek berskala lebih kecil atau bajet rendah.
• Perkhidmatan AWS Terurus Penuh: Walaupun ini meningkatkan kos operasi, ia mengurangkan beban kerja yang berkaitan dengan pengurusan infrastruktur, penskalaan dan penyelenggaraan. Ia sesuai untuk aplikasi yang lebih besar atau apabila kesederhanaan dan penskalaan operasi menjadi keutamaan.

Ringkasan

Nahhhhhhhhhh!!! Malangnya, tiada ringkasan untuk yang ini. Ya, naik semula untuk pemahaman yang lebih baik.

Kesimpulan

Jalan pembelajaran adalah panjang dan mungkin kelihatan sukar, tetapi satu sumber pada satu masa, menambah pengetahuan secara berterusan membawa kita mencapai objektif dan matlamat kita.

Atas ialah kandungan terperinci Menggunakan Apl Django: ECs App Runner dengan Saderi Luaran. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!