PythonアプリをVPSで公開する：前段に何を置くか

レン

手元で動いてるPythonのアプリ、VPSでも同じコマンドで起動すればいい？

プロクラ

そこは変えたほうがいいよ。開発用に用意されている起動方法は、公開向けには作られていない。多くの場合、公式の資料にも「本番では使わないこと」と書かれている。

なぜ開発用のままではいけないのか

開発用のサーバーは、1人が使う前提で作られています。同時に来た要求を順番に捌くため、2人目以降は待たされます。加えて、エラーの詳細が画面に出る設定になっていることが多く、そこにファイルの場所や設定の中身が含まれます。攻撃する側にとっては地図を渡されたのと同じです。

• 同時に来るリクエストを効率よく捌けない
• エラーの詳細を画面に出す設定になっていることがある
• 静的ファイルの配信に向いていない
• 安定して動かし続けることを想定していない

プロクラ

2つめは守りの面で問題だね。エラー画面にファイルの場所や設定が表示されると、それ自体が情報を渡すことになる。本番では必ず無効にしよう。

本番の構成

プロクラ

一般的には、3段構えになるよ。前から順に、役割がはっきり分かれている。

• 前段のWebサーバー: HTTPSの終端、静的ファイルの配信、圧縮
• アプリを動かすサーバー: リクエストを実際に処理する
• アプリ本体
• 前段とアプリの間は、外に公開しない経路で繋ぐ

プロクラ

4つめが守りの要点だよ。アプリ側は 127.0.0.1 で待ち受け、外から直接は繋がらないようにする。入口は前段のWebサーバーだけにまとめる。

常駐させる

• systemdで常駐させるのが素直
• 起動時に自動で立ち上がる設定にする
• 落ちたら再起動する設定と、その回数の上限
• 仮想環境を使っているなら、その中の実行ファイルをフルパスで指定する

プロクラ

4つめでつまずく人が多いよ。手で実行するときは仮想環境を有効にしてから動かすけれど、サービスの起動時にはその手順が入らない。フルパスで指定するのが確実だ。

依存をどう入れるか

システム全体に入れると、他のツールと必要な版がぶつかります。プロジェクトごとに独立した置き場を作れば、片方を更新してもう片方が壊れる、という事故を防げます。入れたものの一覧をファイルに残しておくと、作り直すときにも同じ状態を再現できます。

• 仮想環境を作り、その中に入れる（システム側を汚さない）
• 必要なものを記録したファイルから、同じ状態を再現できるようにする
• 本番でのインストールは、メモリを使うことがある
• 小さいプランでは、別の場所で用意して持ち込む方法もある

レン

開発用のまま公開しない。前段を置いて、アプリは外に出さない。

静的ファイルの扱い

プロクラ

画像やCSSのような静的ファイルは、アプリに処理させず前段のWebサーバーが直接返すほうが速い。設定を分けておこう。

• 静的ファイルを集める処理を、デプロイの手順に含める
• 前段のWebサーバーが、その場所を直接配信する設定にする
• アプリまで届かないので、負荷が下がる
• キャッシュの設定も、前段でまとめて行える

プロクラ

本番では、エラーの詳細を画面に出す設定を必ず無効にしてね。記録はファイルに残し、利用者には簡潔な画面を返す。これが基本の形だよ。