FlaskアプリをVPSに置いて、ブラウザからアクセスできるようになった。
第2回では、そこまで到達しました。
でも実は、その状態はまだ「たまたま動いているだけ」かもしれません。
SSHを切ったら止まる。
サーバーを再起動したら動かない。
そんな不安定な状態では、まだ“サービス”とは言えません。
この回では、FlaskアプリをVPS上で24時間安定して動かすための「止まらない形」を作っていきます。
サーバーを再起動しても止まらず、放っておいても、ちゃんと動いている。
――「ちゃんと動いている自分のサービス」へ。
ここからが、運用の第一歩です。
※ 本記事の構成は、ConoHa VPSを使った環境を前提にしています。
なぜ Flask は「そのまま起動」ではダメなのか
Flaskアプリを作り、VPS上で動かせるようになると、つい python app.py で起動した状態のまま「これで完成かな?」と思ってしまいがちです。
実際、ブラウザからアクセスできていれば、見た目上は問題なく動いているように見えます。
ただ、この起動方法は、あくまで「開発中」や「動作確認用」のものです。
VPS上で使い続けるには、いくつか弱点があります。
たとえば、SSH接続を切るとアプリは止まってしまいます。
サーバーを再起動すれば、当然アプリも起動しません。
つまり、誰かが見に来るタイミング次第では、何も表示されない状態になる可能性があります。
この状態は、「たまたま動いているアプリ」ではあっても、「サービス」とは言えません。
VPS上でアプリを動かすということは、自分が操作していない時間も、きちんと動き続けている必要があります。
そのためには、アプリを“起動し続ける仕組み”をあらかじめ用意しておく必要があるのです。
「止まらない構成」の全体像を先に理解する
Flaskアプリを安定して動かすためには、いきなり設定作業に入るのではなく、まず「全体で何をしようとしているのか」をざっくり理解しておくことが大切です。
今回目指すのは、FlaskアプリをVPS上で24時間動かし続けるための「止まらない構成」です。
といっても、いきなり難しい仕組みを作るわけではありません。
それぞれに役割を持った仕組みを、組み合わせて使うだけです。
構成は、大きく分けて次の4つです。
| 仕組み | 役割 |
|---|---|
| Flask | アプリ本体。画面表示や処理を担当する |
| Gunicorn | Flaskアプリを安定して起動・管理するための仕組み |
| systemd | サーバー起動時にアプリを自動で立ち上げ、落ちたら再起動する |
| Nginx | ブラウザからのアクセスを受け取り、Flaskアプリへ中継する |
この表を見て、「それぞれが何をしているか」がなんとなく分かれば十分です。
今は、細かい違いまで理解する必要はありません。
「役割のイメージ」が持てれば十分です。
次の章からは、この中のひとつずつを、順番に見ていきます。
大切なのは、「この4つが協力して動くことで、Flaskアプリが止まらずに動き続けている」という全体像をつかむことです。
このイメージが持てていれば、このあと出てくる設定内容も、「何のためにやっているのか」を見失わずに読み進められるはずです。
GunicornでFlaskアプリを起動する
ここからは、実際にFlaskアプリを「本番向けの方法」で起動していきます。
まず登場するのが、Gunicornです。
Gunicornは、Flaskアプリを安定して起動・管理するための仕組みで、VPSなどの本番環境でよく使われています。
これまで使ってきた python app.py は、あくまで開発用の起動方法でした。
Gunicornを使うことで、「サービスとして動かす」ための起動方法に切り替わります。
Gunicornとは何をしてくれるのか
Gunicornは、Flaskアプリそのものを別のものに置き換えるわけではありません。
Flaskアプリはそのままに、「どう起動し、どう管理するか」を引き受けてくれる役割を持っています。
たとえるなら、Flaskが中身のアプリだとすると、Gunicornはエンジンのような存在です。
このあと行うのは、Gunicornを使ってFlaskアプリが問題なく起動できるかをまず確認する作業です。
Gunicornでアプリを起動してみる
まずは、Gunicornを使ってFlaskアプリが起動できることを確認します。
この時点では、「一時的に動けばOK」です。まだ自動起動にはしません。
例えば、次のようなコマンドで起動します。
gunicorn app:app
(※ app.py の中にある Flask インスタンス名がapp の場合です)
ブラウザからアクセスして、これまでと同じ画面が表示されれば成功です。
見た目は何も変わりませんが、起動の裏側が、すでに変わっています。
Gunicornでアプリを起動してみる(実際のコマンド)
# 仮想環境を有効化(使っている場合)
source .venv/bin/activate
# Gunicorn をインストール(未インストールの場合)
pip install gunicorn
Flaskアプリ(app.py)があるディレクトリで、次を実行します。
gunicorn app:app
app.py→ ファイル名app→ Flaskインスタンス名
# app.py の例
from flask import Flask
app = Flask(__name__)
ブラウザで
http://サーバーIP:8000
にアクセスして、これまでと同じ画面が表示されれば成功です。
※ この時点ではSSHを切ると止まります(正常な状態)
systemdでFlaskアプリを自動起動させる
Gunicornでアプリが起動できたら、次は「止まらない仕組み」を作ります。
ここで使うのが、systemdです。
systemdは、サーバーの起動やサービスの管理を行う仕組みで、Linuxサーバーでは標準的に使われています。
この仕組みを使うことで、サーバーが起動したときに、Flaskアプリも自動で立ち上がるようになります。
systemdがしてくれること
systemdにFlaskアプリを登録すると、次のようなことができるようになります。
・サーバー起動時に自動でアプリが立ち上がる
・アプリが落ちた場合に、再起動してくれる
・アプリの状態を確認できる
つまり、「起動し忘れる」「気づいたら止まっていた」といった事故を防ぐための仕組みです。
自動起動を設定して確認する
systemdでは、サービスファイルと呼ばれる設定を用意します。
ここに、「どのコマンドでアプリを起動するか」「どのユーザーで動かすか」といった情報を書きます。
設定後にサーバーを再起動して、何も操作していないのにFlaskアプリが動いていれば成功です。
この瞬間が、「止まらない形」ができたと実感できるポイントです。
serviceファイルを作成する
まず、サービスファイルを作成します。
sudo nano /etc/systemd/system/flask-app.service
中身は次のようにします(例)。
[Unit]
Description=Flask App with Gunicorn
After=network.target
[Service]
User=youruser
WorkingDirectory=/home/youruser/yourproject
ExecStart=/home/youruser/yourproject/.venv/bin/gunicorn app:app
Restart=always
[Install]
WantedBy=multi-user.target
🔍 ここで大事なのは3点だけ
User→ 実行ユーザーWorkingDirectory→ Flaskアプリの場所ExecStart→ Gunicornの実行パス
systemd に登録して起動する
# systemd に設定を読み込ませる
sudo systemctl daemon-reload
# サービスを起動
sudo systemctl start flask-app
# 自動起動を有効化
sudo systemctl enable flask-app
状態を確認します。
sudo systemctl status flask-app
active (running) と表示されていればOKです。
再起動しても動くか確認する(重要)
sudo reboot
再起動後、ブラウザでアクセスして何もしなくてもアプリが動いていれば成功です。
👉 ここが「止まらない形になった瞬間」です。
Nginxと組み合わせて公開向け構成にする
Flaskアプリが自動で起動するようになったら、最後に、外部からのアクセスを受け取る役割を整理します。
ここで登場するのが、Nginxです。
Nginxは、ブラウザからのアクセスを受け取り、Flaskアプリへ安全に中継する役割を持っています。
なぜFlaskを直接外に出さないのか
Flaskアプリを、直接インターネットに公開することもできますが、それはおすすめできません。
セキュリティや安定性の面で、専用の受付役を用意した方が安全だからです。
Nginxを間に置くことで、Flaskアプリは「裏側」で動き、Nginxが「表」でアクセスを受け取ります。
アクセスの流れをイメージする
ブラウザからのアクセスは、次のような流れで処理されます。
ブラウザ
→ Nginx
→ Gunicorn
→ Flask
この役割分担によって、Flaskアプリは安定して動き続けることができます。
Nginxをインストールする
sudo apt update
sudo apt install nginx
起動確認:
sudo systemctl status nginx
NginxからGunicornへ中継する設定(最小)
設定ファイルを作成します。
sudo nano /etc/nginx/sites-available/flask-app
内容(最小構成):
server {
listen 80;
server_name _;
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
有効化します。
sudo ln -s /etc/nginx/sites-available/flask-app /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
アクセスの流れを確認する
この状態で:
ブラウザ → Nginx → Gunicorn → Flask
という流れが完成しています。
- Flaskは直接外に出ていない
- Nginxが「玄関」
- Gunicornが「起動係」
🔒 この段階では「やらなくていいこと」
あえて書いておきます。
- HTTPS(SSL)
- ドメイン設定
- worker 数調整
- セキュリティ細か設定
👉 全部、次回以降でOK
今回は「止まらず動く」がゴールです。
ここまでやった人は…
- Flaskアプリはもう“実験”ではありません
- VPSで常駐するサービスになりました
「ちゃんと動いている自分のサービス」になった
ここまで設定できれば、Flaskアプリはサーバーを再起動しても止まらず、放っておいても動き続ける状態になります。
これは、単に「動くアプリ」ではなく、「使われる前提のサービス」に一歩踏み出した状態です。
個人開発であっても、業務ツールであっても、この状態がひとつの基準になります。
まとめ|次はいよいよ独自ドメインへ
今回は、FlaskアプリをVPS上で24時間安定して動かすための「止まらない構成」を見てきました。
・Gunicornで本番向けに起動する
・systemdで自動起動させる
・Nginxで外部アクセスを受け取る
それぞれは難しく見えても、役割を分けて考えれば、一つひとつはシンプルです。
次回は、IPアドレスではなく、独自ドメイン(https://yourname.com)でアクセスできるようにしていきます。
「自分のサービス」を、いよいよ“名前付き”で公開する段階です。
今回紹介した構成は、ConoHa VPSを使った環境を前提にしています。
