Deploying Django to AWS ECS with Terraform
In this tutorial, we'll look at how to deploy a Django app to AWS ECS (via Fargate) with Terraform. Dependencies: Django v4.2.7 Docker v24.0.6 Python v3.12.0 Terraform v1.5.7 Contents Objectives By the end of this tutorial, you will be able to: Explain what Terraform is and how you can use it to write infrastructure as code Utilize the ECR Docker image registry to store images Create the required
【Djangoで非同期処理】Celery×Djangoで作ったアプリをHerokuにデプロイするまでの備忘録｜かえるのほんだな
CeleryでDjangoアプリケーションにタスクキューを実装して、Herokuにデプロイした方法をまとめます。 Djangoアプリケーションにタスクキューを実装するのは今後も結構やるかなと思うので、他のアプリケーションでも使いやすい形で残そうと思います。 参考にしたのは、Celeryの公式様とか、CeleryをDjangoで動かすとか。 あとはHeroku公式のUsing Celery on Herokuあたりです。 ちなみにHerokuの公式ドキュメントに、HerokuはCeleryは完全にサポートしているよ！、と書かれてました。 頼もしい限りです。 やっぱり公式ドキュメントが充実していると開発がはかどりますね。 ドキュメントといえば、Redisのドキュメントもかなり充実してて助かりました。 django-redis documentation ぜひ参考にしてみてください。 もくじ環境
Heroku上のDjangoアプリで静的ファイルをS3から配信する（前編） - orangain flavor
HerokuにDjangoアプリケーションを置いて、静的ファイルもHerokuから配信した場合、USまでのレイテンシがあるので1ファイルごとに結構な時間がかかります。 試しに同じアプリケーションをさくらVPS（大阪）と、Heroku（US）に置いた場合、さくらでは 30ms〜150ms程度でロードできるのに対し、Herokuでは200ms以上かかりました。 HTML1ファイルだけならともかく、CSSやJS、画像のロードにも時間がかかるため、体感時間は結構変わります。 そもそも静的ファイルをアプリケーション・サーバーから配信するのはCPU、ディスク、ネットワークなどのリソースの面でも無駄が多く、推奨されていません。 そこで今回は、静的ファイルをAmazon S3のTokyoリージョンから配信してみました。いわゆる Web Storageパターン です。 長くなったので前後編に分けています。前
uWSGi で Django Channels を動かす - 日記
はじめに ちょっとしたお仕事で Django Channels を uWSGI 上で動かそうとしたら、色々と uWSGI 以外のプロセスも起動していく必要がありました。 ぐぐっても 開発環境や使い方の説明はあるものの、デプロイ時の How to があまり見つからなかったので備忘的に残しておきます。 Django Channels とは？ Django Channels の使い方を説明する記事では無いので、使い方を知りたいひとは、次のページをどうぞ。 Python の WebSocket ライブラリを選定してて、このページに来ちゃった人は次のページも参考にどうぞ。（スケールしないよ、と言う話） 何が問題か？ 前述のページを見ると runserver で普通に動いてるじゃん？と思われますが、本番環境用に uWSGI を使うと uWSGI 上で起動した Django アプリだけでは WebSoc
Djangoでメモリに乗らないサイズのDBを扱うときに気をつける点 - orangain flavor
はじめに Djangoでメモリに乗らないサイズのデータベースを扱うときに、気をつけるべきポイントをまとめます。メモリを大量に消費していつまで経っても処理が終わらなかったり、OOM Killerに殺されたりといった悲しい結末を回避できたら幸いです。 データ量としては、レコード数が数十万から数百万ぐらいで、サイズにして数GB〜十数GBぐらいのイメージです。インデックスを適切に張るといった、Django特有でないポイントは取り上げません。Djangoのバージョンは1.5系を対象にしています。 バッチ処理のDEBUGに気をつける 症状 DEBUG = Trueの場合、バッチ処理で大量のクエリを発行するとメモリを食いつぶすことがあります。 原因 実行したすべてのSQLが記録されるためです。defaultのデータベースを利用している場合は、django.db.connections['default
djangoのQuerySetで大量のデータを扱う - logiqboard
メモリに載り切らないような大量のデータを扱うときは何かしらの工夫が必要で、djangoのQuerySetも例外ではありません。 簡単な例として、以下のコードをメモリが多くない環境で実行すると、ループに入る前にメモリをドカ食いして落ちます。 many_many_objs = MyDBLog.objects.all() # 1億件ぐらいあるとする for log in many_many_objs: print(log.body) どうする 件数が大きくなりえるQuerySetを扱う場所では、QuerySetを分割して扱うようにします。 QuerySetはスライスが使えるので、うまく活用しましょう。 def chunked(queryset, chunk_size=1000): start = 0 while True: chunk = queryset[start:start + chunk
Django1.8からテンプレートエンジンにJinja2を選べるようになっていた #djangoja - Qiita
この記事はTokyoDjangoMeetup #3参加中に書きました。 Django1.8からテンプレートエンジンにJinja2を選べるようになりました。 設定方法は、設定ファイルのTEMPLATESを以下のように書くだけです。 TEMPLATES = [ { # ↓デフォルトの値をこれに書き換える 'BACKEND': 'django.template.backends.jinja2.Jinja2', 'DIRS': [], 'APP_DIRS': True, 'OPTIONS': { # context_processorsがあると動かないので使わないようにする(後述) #'context_processors': [ # 'django.template.context_processors.debug', # 'django.template.context_processors.
Djangoでgraphene_djangoを使ってGraphQL API - Qiita
この記事は Django Advent Calendar 2016 19日目の記事です。 GraphQLのためのPython製フレームワークに graphene があります。grapheneにはO/R Mapperで使いやすくしたライブラリがいくつかあります。 今回はその中の1つ graphene-django を使ってみます。 インストール venv環境を作ってactivateしておきましょう。 $ ~/ng/home/src/develop/pyvm/pythons/Python-3.5.2/bin/python3 -m venv env $ source env/bin/activate (env) $ (env) $ pip install graphene_django Collecting graphene-django Using cached graphene-django
Can Django flush its database(s) between every unit test?
Django (1.2 beta) will reset the database(s) between every test that runs, meaning each test runs on an empty DB. However, the database(s) are not flushed. One of the effects of flushing the database is the auto_increment counters are reset. Consider a test which pulls data out of the database by primary key: class ChangeLogTest(django.test.TestCase): def test_one(self): do_something_which_creates
gunicorn(>=19.2)ではmax_requestsと一緒にmax_requests_jitterも使おう - Qiita
max_requestsとは何か？ gunicornのmax_requestsパラメータを指定すると、各ワーカープロセスが max_requests 回数分リクエストを捌くとプロセスを自動再起動してくれるようになります。 これによってメモリリークを回避し、サーバーのリソース逼迫を防ぐことができます。 max_requestsだけだとどんな問題があるか？ gunicornでは各ワーカープロセスにほぼ均等にリクエストが割り振られるため、全ワーカープロセスが一斉にmax_requestsに達して再起動してしまうケースが発生します。 そうなるとリクエストを捌けるワーカーがいない状態が一瞬できるので、ユーザー側から見ると「あれっ、このサイト突然激重になった？」ということがありえます。 バージョン19.2からの新機能max_requests_jitter そこで、バージョン19.2からmax_requ
Introduction to develop Django plugin
PyCon 2016 はじめて作るDjangoプラグイン
Python: mod_wsgi の組み込みモードとデーモンモードについて - CUBE SUGAR CONTAINER
Python で Web アプリケーションを開発する場合、WSGI という仕様に沿った形で作られているとアプリケーションのポータビリティが向上する。 WSGI の仕様に沿っているアプリケーションは、異なる実装の WSGI サーバであっても動作させることができるためだ。 今回は数ある WSGI サーバの中でも Apache httpd 上で動作することで有名な mod_wsgi について扱う。 この mod_wsgi にはふたつの動作モードがあり、それぞれ組み込みモード (embedded mode) とデーモンモード (daemon mode) という名前がついている。 今回は mod_wsgi を組み込みモードとデーモンモードのそれぞれで動作させた上で、両者がどのように異なるのかについて調べていく。 尚、今回の検証には CentOS7 を使った。 $ cat /etc/redhat-re
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Kubernetes Engine で Django を実行する | Python | Google Cloud
Talks Schedule
https://cdn.jsdelivr.net/gh/Miserlou/Talks@8f7cd4b7/zappa-djangocon-2017/djangocon.html
Django REST FrameworkでModelSerializer.to_representationが遅すぎる場合にやること（雑な調べ方） - Heppoko Binbo Yarou no Newbie Nikki
GitHub - logandk/serverless-wsgi: Serverless plugin to deploy WSGI applications (Flask/Django/Pyramid etc.) and bundle Python packages
The django-rest-framework documentation translation project on Transifex
Compatible Django Middleware
MH09 uWSGI/Dockerを利用したWebサービス運用事例
