Posted inFedora

Fedora Server: GunicornとNginxによるプロフェッショナルなPythonデプロイ

Fedora tutorial - IT technology blog
Fedora tutorial - IT technology blog

本番環境で ‘python main.py’ に頼るのは卒業しましょう

ローカル環境ではスムーズに動くのに、サーバーにデプロイして数十人のユーザーがアクセスした途端にアプリがクラッシュしてしまう…。そんな経験はありませんか？サーバー上で直接 python app.py コマンドを実行して運用するのは非常に危険な罠です。ローカル環境ではオートリロード機能のおかげでデバッグが容易ですが、この方法をそのまま本番環境に持ち込むと、システムは極めて脆弱になります。

FlaskやDjangoに内蔵されているサーバーは、通常シングルスレッド（single-threaded）で動作します。同時に10件の重いリクエストが来ると、アプリケーションは簡単にパンクしてフリーズしてしまいます。筆者はFedoraをメインのワークステーションとして2年間使用していますが、パッケージの更新速度が非常に素晴らしいと感じています。しかし、パッケージが常に最新であるため、設定には細心の注意が必要です。高負荷に耐えるためには、標準的なモデルである Pythonアプリ <—> Gunicorn (WSGI) <—> Nginx (リバースプロキシ) を採用する必要があります。

ステップ 1: Fedora Serverでの環境構築

まずはシステムのアップデートから始めましょう。Fedoraはパッチのリリースが非常に早いため、常に最新の状態に保つことが重要です。

sudo dnf update -y
sudo dnf install python3-pip python3-devel nginx -y

不変のルール：常に仮想環境（Virtual Environment）を使用してください。システムのPythonに直接ライブラリをインストールすると、DNFなどPythonベースで動いているFedoraの管理ツールを壊してしまうリスクがあります。

mkdir ~/my_app && cd ~/my_app
python3 -m venv venv
source venv/bin/activate
pip install gunicorn flask

ステップ 2: SystemdによるGunicornの管理

Gunicornはリクエストを処理するために「ワーカー」（子プロセス）を作成します。コマンドを手動で実行する代わりに、systemd に管理を任せましょう。これにより、アプリのクラッシュ後やサーバーの再起動後も自動的に起動するようになります。

ファイル作成: /etc/systemd/system/my_app.service

[Unit]
Description=Gunicorn instance serving my_app
After=network.target

[Service]
User=fedora
Group=fedora
WorkingDirectory=/home/fedora/my_app
Environment="PATH=/home/fedora/my_app/venv/bin"
ExecStart=/home/fedora/my_app/venv/bin/gunicorn --workers 3 --bind unix:my_app.sock -m 007 wsgi:app

[Install]
WantedBy=multi-user.target

実践的な数値： --workers 3 設定については、(2 x CPUコア数) + 1 という計算式を適用しています。例えば、1 CPUのVPSプランを使用している場合、3ワーカーが理想的です。Gunicornの各ワーカーはアプリ의負荷に応じて通常50MBから100MBのRAMを消費するため、所有しているリソースに合わせて調整してください。

ステップ 3: Nginx – 最前線のセキュリティガード

なぜユーザーを直接Gunicornに接続させないのでしょうか？それは、Nginxの方が静的ファイル（画像、CSS）の処理が数倍速いからです。また、Gzip圧縮、リクエスト制限のサポート、および基本的なHTTP攻撃からのアプリ保護も提供します。

設定ファイルの場所: /etc/nginx/conf.d/my_app.conf

server {
    listen 80;
    server_name your_domain.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://unix:/home/fedora/my_app/my_app.sock;
    }

    location /static/ {
        alias /home/fedora/my_app/static/;
    }
}

注意：Fedora上のNginxにはUbuntuのような proxy_params ファイルがデフォルトで用意されていないため、重要なヘッダーを上記のブロックに直接追加しています。

sudo nginx -t && sudo systemctl restart nginx

ステップ 4: Fedoraの「洗礼」 – SELinuxによる502エラーへの対処

すべてが正常に見えるのに 502 Bad Gateway エラーが発生する場合、主な原因はSELinuxです。Fedoraはデフォルトで厳格なセキュリティモードが有効になっており、Nginxがユーザーのホームディレクトリ内にあるソケットファイルを読み取るのをブロックします。

SELinuxを完全に無効化するのではなく（非常に危険です）、正規の方法で権限を付与しましょう。

# Nginxのネットワーク接続を許可
sudo setsebool -P httpd_can_network_connect 1
# Nginxのソケットへのアクセス権限を付与
sudo chcon -t httpd_sys_rw_content_t /home/fedora/my_app/my_app.sock

長期的な安定性のために、ソケットを /run/my_app/ に移動することをお勧めします。ここはシステムサービスが通信ファイルを置く標準的な場所であり、ユーザーディレクトリの権限に関するトラブルを避けることができます。

確認と監視

稼働を開始したら、ログの監視は必須です。エラーをリアルタイムで追跡するために、通常以下のコマンドを使用します。

sudo journalctl -u my_app -f

CPU使用率が急上昇した場合は、htop を使用してください。Fedoraはスレッドを非常に分かりやすく表示するため、コードのロジックエラーによりどのワーカーがフリーズしているかを正確に特定できます。アプリケーションのデプロイは難しくありません。大切なのはコードとインフラの調和です。セットアップの成功を祈ります！

Share:
Tags: