Django アプリのデプロイ: 外部 Celery を使用した EC アプリ ランナー

ちょっと待って…

本番環境に移行するのに忙しいという状況に誰もが遭遇したことがありますが、展開プラットフォームの選択には多くの要因が考慮されます。そうですね、AWS を使います。通常、プラットフォームに固執した後は、アーキテクチャ、コスト、信頼性、スケーラビリティ、可用性、実現可能性などのいくつかの要素に頼ることができます。何だと思う！！！ AWS はそれらすべてにおいて信頼されているため、これは信頼性、スケーラビリティ、可用性、実現可能性に関するものではありません。このチュートリアルでは、Django アプリのいくつかのアーキテクチャの良い点と悪い点を特定します。

先に進む前に、何が起こっているかを完全に理解するために、いくつかの前提条件を理解しましょう。

:) このチュートリアルに含まれるすべてのコードは、オープンソースとして利用可能になります。ご自由に足跡を入れてください

前提条件

先に進む前に、次のことを行う必要があります:

• AWS アカウントをお持ちです
• Django の知識がある方
• キュー、タスク、ブローカーとは何かを理解する

キャッシュとは何か、なぜキャッシュするのか

キャッシュは、頻繁にアクセスされるデータを高速アクセスの場所に一時的に保存し、このデータの取得にかかる時間を短縮するために使用される技術です。 AWS では、キャッシュによりプライマリ データベースと API の負荷が最小限に抑えられ、アプリケーションのパフォーマンスとスケーラビリティが向上し、エンドユーザーの応答時間が短縮されます。

効率を高め、レイテンシーを削減し、コストを削減するためにキャッシュを行います。キャッシュはデータをアプリケーションの近くに保存することで、データベース クエリの頻度、ネットワーク トラフィック、および計算負荷を軽減します。これにより、データの取得が高速化され、ユーザー エクスペリエンスが向上し、リソース使用量が最適化されます。これは、高トラフィックのアプリケーションにとって重要です。

ウォーミングアップをしましょう

1. EC2:
   Elastic Compute Engine の正式な意味から、EC2 は AWS データセンターにある Web サーバーです。言い換えれば、EC2 は AWS から取得できる仮想的なものです。利用可能なすべての機能を備えた「従量課金制プラン」の下で、非常に安い月額料金で入手できます。

2. AWS アプリランナー:
   これは、Web アプリケーションと API の実行とスケーリングを簡素化し、開発者がインフラストラクチャ管理なしでコード リポジトリやコンテナ イメージから迅速にデプロイできるようにするフルマネージド サービスです。

3. セロリとジャンゴセロリ:
   Celery は、Python でリアルタイム処理を行うためのオープンソースの分散タスク キューです。 Django Celery は Celery を Django フレームワークと統合し、Django アプリケーション内での非同期タスクの実行、定期タスク、およびバックグラウンド ジョブ管理を可能にします。このテクノロジーの使用例はさまざまです。これには、通信サービス (SMS、電子メール)、スケジュールされたジョブ (Cron)、およびデータ集約、機械学習モデルのトレーニング、ファイル処理などのバックグラウンド データ処理タスクが含まれます。

4. Amazon RDS (リレーショナルデータベースサービス):
   これは、クラウドでのリレーショナル データベースのセットアップ、運用、スケーリングを簡素化するマネージド データベース サービスです。 MySQL、PostgreSQL、Oracle、SQL Server などのさまざまなデータベース エンジンをサポートし、自動バックアップ、パッチ適用、高可用性を提供し、ユーザーをデータベース管理タスクから解放します。

このコンテキストでの EC2 と App Runner の比較

アーキテクチャ

アプリがどのように構成されているか、そして展開セットアップがどのように動作するかを調べてみましょう。

AWS App Runner (ECR) を使用したデプロイメントセットアップ

1. 
   コードを GitHub にプッシュし、CodePipeline ワークフローをトリガーします。 CodePipeline は CodeBuild を使用して、リリースのバージョン管理のために Elastic Container Registry (ECR) に保存される Docker イメージを作成します。このチュートリアルでは、Virtual Private Cloud (VPC) 構成をスキップします。 CloudWatch を使用してログを継続的に監視することで、アプリケーションの健全性を確保します。さらに、静的ファイル用に AWS RDS および S3 によって提供される Postgres を使用するためのプロジェクトの迅速な設定も可能です。

2. AWS EC2インスタンスを使用したデプロイ
   
   同様のプロセスを使用して、バージョン管理と ECR を省略し、コードを GitHub にプッシュし、CodePipeline をトリガーします。CodePipeline は、CodeBuild を使用して、バージョン管理のために ECR に保存される Docker イメージを作成します。 EC2 インスタンスはこれらのイメージをプルして VPC 内にアプリケーションをデプロイし、エンドユーザーがアクセスできるようにします。アプリケーションは、データ ストレージの場合は RDS、静的ファイルの場合は S3 と対話し、CloudWatch によって監視されます。必要に応じて、certbot などのオプションを使用して、SSL 構成をこのインスタンスに追加できます。

価格比較表

ここでは、典型的な使用シナリオに基づいた EC2 と App Runner の仮想の価格比較を示します:

管理のしやすさ

これら 2 つのリソースの管理方法について簡単にまとめてみましょう。

スケーラビリティ

導入速度

カスタマイズと制御

安全

プロジェクトのセットアップ

プロジェクトの比較はプロジェクトの設定自体には依存しないことを前提としています。 AWS の celery 構成を使用した基本的な Django アプリケーションを用意します。
Django を使用した基本的なプロジェクトを進めていきます。

依存関係のインストールとプロジェクトの作成:

リーリー

リーリー

リーリー

1- セロリの準備

リーリー

リーリー

init.py を更新して、Django の起動時にアプリが確実に読み込まれるようにします。リーリー
4- タスクを作成します

リーリー
5- ここで、単純な Json 応答を含む単純なビューを追加しましょう。

リーリー
6- アクセスを可能にするエンドポイントがなければ、ビューを持つことはできません

リーリー
7- アプリの URL をプロジェクト全体の一般的な urls.py に追加します。

リーリー
環境変数の追加:

リーリー
これらすべての手順を適切にフォローアップすると、次の出力が得られます:

AWS環境のセットアップ

AWS に出荷しているため、いくつかのリソースを設定する必要があります

新しい VPC (仮想プライベート クラウド) の作成

私たちは、リソース間の安全なアクセスと通信のために、隔離された環境とネットワークを作成します。
セキュリティグループの作成

以前に作成した VPC の下にセキュリティ グループを作成し、受信ルールと送信ルールを TCP ポート 6379 (Redis ポート) に追加します。
ElasticCache から RedisOSS を作成する

基本的に、AWS Elastic Cache はキャッシュに関して 2 つの種類、つまり RedisOSS と memCache を提供します。 RedisOSS は高度なデータ構造と永続化機能を提供しますが、Memcached はよりシンプルで、キーと値のペアの高速キャッシュに重点を置いています。 Redis は、Memcached とは異なり、レプリケーションとクラスタリングもサポートしています。ビジネスに戻り、Redis に戻ります。

Elastic Container Registry (ECR) のセットアップ

ECR イメージの作成は非常にシンプルで簡単です。
1: App Runner をデプロイするためのアップデート

以下の手順に従って、アプリランナーを実行します。

ここでは非常に技術的になる必要があります。 VPC は、ほとんどのリソースが置かれている安全なネットワークです。アプリランナーは VPC 内に見つからないため、これらのリソース間の通信に安全な手段を提供する必要があります。
資格情報 ユーザーの資格情報

このチュートリアルでは、ワークフローを ECR に接続するための承認が必要になります。次に、AmazonEC2ContainerRegistryFullAccess アクセス許可ポリシーを追加して、イメージを AWS ECR にプッシュできるようにします。

結果

すべてが完了すると、このツリー構造が完成します。

このチュートリアルのコードベース全体は My GitHub にあります。

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 ; 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

コストの概要

• AWS 無料利用枠を使用したセットアップ: 無料利用枠の制限内にある場合は、基本的に無料です。使用量が無料枠の許容範囲を超えると、潜在的な費用が発生する可能性があります。
• すべての有料 AWS サービスを使用したセットアップ: EC2、Elasticache、および RDS 用の 1 つの t2.micro インスタンスの継続運用を想定し、データ転送とストレージの追加コストを想定して、月額約 41.34 ドルと見積もられます。

注: 料金は概算であり、地域や特定の AWS の料金変更によって異なる場合があります。特定の要件に応じた最も正確なコスト見積もりを得るには、常に現在の AWS 料金ページを確認してください。

分析

• EC2 でのセルフマネージド: このアプローチは、特に AWS 無料枠を使用する場合にコスト効率が高くなります。より多くのセットアップと手動メンテナンスが必要ですが、環境を完全に制御できます。小規模または低予算のプロジェクトに最適です。
• フルマネージド AWS サービス: これにより運用コストは増加しますが、インフラストラクチャの管理、スケーリング、メンテナンスに関連する作業負荷は軽減されます。大規模なアプリケーション、または操作の簡素化とスケーリングが優先される場合に適しています。

まとめ

いやぁぁぁぁぁぁぁぁぁ！！！残念ながら、この件に関する要約はありません。はい、理解を深めるために前に戻ってください。

結論

学習の道のりは長く、難しく見えるかもしれませんが、一度に 1 つのリソースを使い、継続的に知識を追加することで、目的と目標を達成することができます。

以上がDjango アプリのデプロイ: 外部 Celery を使用した EC アプリ ランナーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。