なんか、仮想マシンで簡易的な競プロローカルサーバ作りたくね？ その2

その1 URL https://qiita.com/Wing2C1/items/6b3a522803a0fc8eaab4
その3 URL https://qiita.com/Wing2C1/items/e11cf2e2ce938205d130
その4 URL https://qiita.com/Wing2C1/items/dbb2c728a8300c3b2919
今回の記事にあたっての画像や記述は基本2025/11/25のときのものであることを断っておこう。

3.バックアップ

今回の主題入る前に、今回ではネットワークの設定などをいじる。手順ミスなどを犯し、到底一人では戻れなくなる場合が考えられることから、バックアップを作ることが望ましい。そのため、この仮想マシン自体のクローンを作ることで対処しよう。ただし、そのクローン自体も源と同じだけのデータ量を持つため、ストレージには注意しなくてはならない。
VirtualBox Managerを開き、仮想マシンを右クリック。

クローンを押す。

完了を押すとクローンが作られる。

(上のプロセッサーは3で合っているので、4なのは気にしなくていい)
ところで、これと似たような機能にマシンのエクスポートがあるが、これは.ovaのファイル一本だけになり、別のドライブや別のホストマシンに移すとき使えやすい。もし、十分な大きさの容量を持つUSBなどがある場合はエクスポートしても良いだろう。今回の記事では使わないので自身で調べてやってほしい。

4.サーバー側の環境設定

ここが一番基本で大事。今回の記事はこれで終わりにしてもいいくらいだ。

導入

今回使っていくのは、DjangoというPythonで実装されたWebアプリケーションフレームワーク。を使っていく。Webアプリケーションを効率的に開発するための「枠組み」や「土台」となるもののことだ。基本的なユーザー認証、データベース接続、URLルーティング、セキュリティ対策などが備わっていることから、あとはそれに依存した開発を行えばいい。
Pythonのライブラリをインストールするためには、Pythonのパッケージ管理システム「pip」を用いる必要がある。このOSに標準搭載されているのはPython 3という新しいバージョンのため

sudo apt install python3-pip

でインストール可能。また、pipを用いたとしてもそのパッケージが仮想マシン内の他プロジェクトや他ライブラリなどと競合する可能性がある。そこで、venv(virtual environment)を用いると開発環境を分離できるため、そのプロジェクト専用のライブラリ集ができてスッキリするのだ。

sudo apt install python3-venv

でインストール。ここで、作業場を作成しよう。

mkdir [name]

で作成することができる。(mkdirはmake directoryの略である)
私はworkdirという名前にでもしようか。これからは作業場となるディレクトリはworkdirという名称を用いるが、もちろん違う名前ならそれで入力すること。

cd workdir

cdコマンドでディレクトリ間を移動する。ちなみに

cpserver@CP-server:~/

はホームディレクトリという場所にいる意味である。デフォルトで来る場所みたいなイメージだ。
実際にpwdというコマンドを打ってみよう。これは今いるディレクトリの絶対パスを返す。

cpserver@CP-server:~$ pwd
/home/cpserver

ホームディレクトリのユーザー(cpserver)以下のディレクトリだということがわかるはずだ。
さて、仮想環境の作り方とは

python3 -m venv [newenvname]

で作る事ができる。venvnameはなんでも構わないが、venvの方がわかりやすいから私はそうする。venvじゃなくてももちろん良い。無効化するときは

deactivate

を打つだけでいい。
さて、今、homeのuserのCPappというディレクトリにいるだろう。そこが活動場所であり、仮想環境のライブラリが入っている場所だ。

source ./venv/bin/activate

で仮想環境を有効化できる。そうすると、ターミナルの一番左に(venv)という文字列が現れたはずだ。それが仮想環境にいる意なのである。ここで、便利なコマンドをインストールしておこう。

sudo apt install tree

treeコマンドをインストールしておくと

tree -L 3

を入力するだけで、そのディレクトリ以下の3階層までが以下のような形で出力される。これを行えば、どこにあるかわからないファイルを探すときなどに便利だ。オプションなどは tree -helpで出てくるので上手く使えるようにしておくと良い。

(venv) cpserver@CP-server:~/workdir$ tree -L 3
.
└── venv
    ├── bin
    │   ├── Activate.ps1
    │   ├── activate
    │   ├── activate.csh
    │   ├── activate.fish
    │   ├── pip
    │   ├── pip3
    │   ├── pip3.13
    │   ├── python -> python3
    │   ├── python3 -> /usr/bin/python3
    │   └── python3.13 -> python3
    ├── include
    │   └── python3.13
    ├── lib
    │   └── python3.13
    ├── lib64 -> lib
    └── pyvenv.cfg

8 directories, 11 files

さあ次は、本丸となるDjangoをインストールしよう。

pip install django

インストールが完了したら、早速プロジェクトを立ち上げよう。

django-admin startproject [projectname]

今回、プロジェクトの名前はCPsiteとした。そうすると現在のディレクトリ直下にできているはずだ。lsコマンドで確認すると

(venv) cpserver@CP-server:~/workdir$ ls
CPsite  venv

できているようだ。cd で入り、treeコマンドで何があるか一覧化してみる。

(venv) cpserver@CP-server:~/workdir/CPsite$ tree
.
├── CPsite
│   ├── __init__.py
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

2 directories, 6 files

manage.pyとは、Djangoプロジェクト内で利用できるコマンドラインユーティリティのことだ。python3 manage.py <command>のように実行し、開発サーバーの起動、マイグレーション（データベースの変更管理）、アプリケーションやスーパーユーザーの作成など、プロジェクトの様々な操作や管理を簡単に行うことができるものだ。基本的に同じディレクトリ内でmanage.pyを行う。
更に内部にCPsiteというディレクトリが出来ている。この中身について軽く説明をする。

__init__.py：このファイルはそのディレクトリがPythonのパッケージであることを示すための空ファイルで、特別な初期化処理を書くこともあるが、普通は空。

asgi.py：ASGIとはAsynchronous Server Gateway Interfaceの略で、非同期でアプリケーションを実行する様のインタフェース定義。ASGI対応のウェブサーバーがDjangoアプリケーションを動かすためのエントリポイントで、非同期通信やWebSocketなどを扱う。

settings.py：Djangoプロジェクトの設定ファイルで、データベース設定、使用するアプリ、ミドルウェア、テンプレート設定、言語設定などを一括で管理する。

urls.py：URLのルーティングを管理するファイルで、どのURLにどのビュー関数を割り当てるかを定義する。

wsgi.py：WSGIとはWeb Server Gateway Interfaceの略で、pythonにおいてWebサーバとWebアプリケーションが通信するための標準化されたインタフェース定義。

この中で、重要なのはmanage.py,settings.py,urls.pyで、他はおそらく触ることがないだろう。
さて、manage.pyと同じディレクトリの中で以下のコマンドを実行してみよう。

python3 manage.py runserver

さて、manage.pyと同じディレクトリの中で以下のコマンドを実行してみよう。

python3 manage.py runserver

(venv) cpserver@CP-server:~/workdir/CPsite$ python3 manage.py runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
November 25, 2025 - 07:25:57
Django version 5.2.8, using settings 'CPsite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
For more information on production servers see: https://docs.djangoproject.com/en/5.2/howto/deployment/

警告はとりあえず無視して、http://127.0.0.1:8000 にアクセスしてみる。

出来てそうだ。ターミナルで操作を続行するにはCtrl+Cで強制終了する。
さて、警告の意味だがこれは開発用サーバーだから運用環境では使用するなと言っている。なら、今からWebサーバーをインストールしよう。

sudo apt install nginx

でnginx(エンジンエックス)をインストールする。

前提として、Webサーバーとはユーザーからのリクエストを受けて処理を実行し、ユーザーにレスポンスを返すためのシステム。Webアプリにはこれがないと、このQiitaのようにページを表示することすら叶わないだろう。
その中で、nginxは処理能力の高さや並行処理能力、メモリ消費量の少なさなどがポイントで、性能の高さが評価されて現在世界のWebサーバーソフトとしてトップに立っている。他のWebサーバーにApacheがあるが、同時接続が増えるとメモリ消費量が大きくなってしまうというデメリットがある。
特に今回の場合だと4096MBしかメインメモリーがないため、nginxに白羽の矢が立ったというわけである。また、nginxは静的ファイルの扱いが得意。

静的ファイルとは、Webサイトの見た目や動作、メディアを担っている。例えば、CSSやjpeg,png,gifといった画像データに、フォントファイルも含まれる。

対して、動的ファイルは、リクエストごとに変化するファイルで、データベースに問い合わせたり、ユーザーセッション情報の確認などを行う。プログラムはこれらの処理結果に基づいて、その場限りの新しいHTML、JSONデータ、またはその他のコンテンツを生成し、Webサーバー経由でクライアントに返す。

だが、nginxだけだとdjangoもといpythonアプリケーションを実行する能力がなく、直接やりとりをすることが出来ない。そのため、gunicornというライブラリをインストールすることで仲介をしてくれる。

pip install gunicorn

gunicornの設定

インストールし終わったら、実際に動かせるよう設定していく。
最初は、gunicornの設定から行こう。
socketファイルの作成を行う。これはプロジェクト内にsockファイルを生成する。nginxと連携させるためにも非常である。

sudo nano /etc/systemd/system/gunicorn.socket 

/etc/systemd/system/gunicorn.socket

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

SocketUser=www-data

[Install]
WantedBy=sockets.target

セクション	ディレクティブ	解説
Unit	Description	「socketファイル」の説明文を記載。
Socket	ListenStream	後述する「serviceファイル」のポート番号を指定。 今回は「sockファイル」のため上記のように記載。
Socket	SocketUser	バックグラウンドで常に操作を実行するユーザー www-dataはWebサーバーがデフォルトで 通常の操作に使用するユーザー。
Install	WantedBy	systemctl enableを有効化させ、仮想マシン起動時に勝手に起動する永続化ができる。

Serviceファイルの作成を行う。
このファイルは、指定したDjangoプロジェクトをWSGI仕様に準拠したGunicornで起動するためのコマンドを登録しておくものだ。

sudo nano /etc/systemd/system/gunicorn.service 

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=cpserver
Group=www-data
WorkingDirectory=/home/cpserver/workdir/CPsite
ExecStart=/home/cpserver/workdir/venv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          CPsite.wsgi:application
[Install]
WantedBy=multi-user.target

セクション	ディレクティブ	解説
Unit	Description	サービスの説明文。
Unit	Requires	必須の依存関係を指定。
Unit	After	起動順序を指定。network.targetの設定が完了 した後に起動する。
Service	User	Gunicornプロセスを動作させるユーザーを指定。 通常今の非rootユーザー
Service	Group	Gunicornプロセスを動作させるグループを指定。
Service	WorkingDirectory	Gunicornプロセスが実行される 作業ディレクトリを指定。
Service	ExecStart	gunicornを起動するコマンドとそのオプション。
Install	WantedBy	socketと同じく。

Daemon(デーモン)の再読み込みを実施する。Daemonはメインメモリ上に常駐して特定の機能を提供するプログラムのことだ。

sudo systemctl daemon-reload

これで、gunicornを起動してみる。

sudo systemctl start gunicorn
sudo systemctl status gunicorn

statusを打つと状態を確認できる。

(venv) cpserver@CP-server:~/workdir$ sudo systemctl status gunicorn
● gunicorn.service - gunicorn daemon
     Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; preset: >
     Active: active (running) since Tue 2025-11-25 18:18:36 JST; 8s ago
 Invocation: 5ce68723b6d34a7d853d35123174101e
TriggeredBy: ● gunicorn.socket
   Main PID: 5485 (gunicorn)
      Tasks: 4 (limit: 4620)
     Memory: 96.4M (peak: 96.7M)
        CPU: 1.069s
     CGroup: /system.slice/gunicorn.service
             ├─5485 /home/cpserver/workdir/venv/bin/python3 /home/cpserver/wo>
             ├─5486 /home/cpserver/workdir/venv/bin/python3 /home/cpserver/wo>
             ├─5487 /home/cpserver/workdir/venv/bin/python3 /home/cpserver/wo>
             └─5488 /home/cpserver/workdir/venv/bin/python3 /home/cpserver/wo>

11月 25 18:18:36 CP-server systemd[1]: Started gunicorn.service - gunicorn da>
11月 25 18:18:36 CP-server gunicorn[5485]: [2025-11-25 18:18:36 +0900] [5485]>
11月 25 18:18:36 CP-server gunicorn[5485]: [2025-11-25 18:18:36 +0900] [5485]>
11月 25 18:18:36 CP-server gunicorn[5485]: [2025-11-25 18:18:36 +0900] [5485]>
11月 25 18:18:36 CP-server gunicorn[5486]: [2025-11-25 18:18:36 +0900] [5486]>
11月 25 18:18:36 CP-server gunicorn[5487]: [2025-11-25 18:18:36 +0900] [5487]>
11月 25 18:18:36 CP-server gunicorn[5488]: [2025-11-25 18:18:36 +0900] [5488]>

他のコマンドも紹介しておく。

sudo systemctl restart gunicorn # gunicornの再起動コマンド
sudo systemctl stop gunicorn # gunicornの停止コマンド

最後に

sudo systemctl enable gunicorn

を打っておくと、仮想マシンを起動したときgunicornを自動で起動させてくれる。

nginxの設定

次に、nginxの設定を執り行う。

sudo nano /etc/nginx/conf.d/cpsite.conf

/etc/nginx/conf.d/cpsite.conf

server {
	listen 80;
	server_name cp-server;
	
	location /static {
		alias /usr/share/nginx/html/static;
	}

	location /media {
		alias /usr/share/nginx/html/media;
	}

	location / {
		proxy_pass http://unix:/run/gunicorn.sock;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
		proxy_redirect off;
		proxy_set_header X-Forwarded-Proto $scheme;
	}
}

簡単に設定内容を説明すると、nginxはHTTPポート80番で待ち受け、ドメイン名をcp-serverと指定している。これは、設定したVM名である。なぜ、VM名である必要があるかと言うと、仮想マシンのDebianではデフォルトでその名前を登録するからだ。

cat /etc/hosts

を見てほしい。

cpserver@CP-server:~$ cat /etc/hosts 
127.0.0.1 localhost 
127.0.1.1 CP-server.myguest.virtualbox.org CP-server 
# The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters

ここで、VM 名である CP-server が 127.0.1.1 に紐付けられている。
また、Linux の名前解決ではホスト名の大文字・小文字を区別しないため、CP-server に対して cp-server でアクセスしても同じように 127.0.1.1 に解決される。その結果、http://cp-server というアクセスはこの仮想マシン自身を指すことになり、そこで動作している Nginx が応答する仕組みとなっている。
また、nginxが直接処理するファイル（静的コンテンツ）の場所として/usr/share/nginx/html/staticと/usr/share/nginx/html/mediaを指定している。そしてリクエストの転送先として、さっき指定したソケットファイルを経由してgunicornにリクエストを渡しているという形だ。
設定ファイルの内容が間違っていないかは

sudo nginx -t

で確認できる。

(venv) cpserver@CP-server:~/workdir$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

大丈夫そうだ。

sudo systemctl reload nginx

で設定内容を反映させる。

データベースの導入

今回は競技プログラミング風Webアプリケーションを作成するのだから、膨大なデータを効率的に集約、共有、管理、活用し、業務効率化や迅速な意思決定に役立てるためのシステム。そう、データベースが必要なのだ。実は、Djangoはデフォルトでsqliteというデータベースが存在するのだが、複数同時アクセスや並列処理は苦手なため違うデータベースに変えておくと将来運用するときに、便利になるだろう。
そこで、高速で信頼性が高いMySQLを用いることにしよう。数あるデータベースの中でも世界的に支持されているオープンソースデータベースで、1995年にOracle社からリリースされて以降、企業Webサイト、Webアプリケーションなどのデータベース管理に広く利用されている。だから、MySQLを学習するための解説がインターネット上に数多く公開されており、ほとんどの質問や問題に対する回答がオンラインで見つかる。
Good Pointだわ :)

そのくせに、なんとdebianのaptパッケージにデフォルトで入ってない！許せないのでパッケージを追加してそこからダウンロードする。
https://dev.mysql.com/downloads/repo/apt/
このページにそのパッケージがあることを判明した。これを用いよう。
curlコマンドを用いてインストールする。デフォルトでcurlコマンドはないため、

sudo apt install curl

を実行してから以下を実行。

curl -LO https://dev.mysql.com/get/mysql-apt-config_0.8.36-1_all.deb
sudo dpkg -i mysql-apt-config_0.8.36-1_all.deb

curlコマンドは、URLからデータを転送するためのツールとして考えていい。-Lはリダイレクトがあった場合に追跡してファイルをダウンロードするオプション。-OはURLのファイル名（mysql-apt-config_0.8.36-1_all.deb）をそのまま使って、現在のディレクトリに保存するオプション。
dpkgは、Debianパッケージ（.debファイル）を管理するためのツール。そこに-iをつけてインストールを行う。
さて、dpkgを行うと以下の画面になると思う。

欲しいのは現在のバージョンのMySQL Serverとその周辺ツールなので上がmysqlで下がEnabledならそのまま矢印キーでOKまで行きEnterで選択する。もし、何かが違うならば、該当のオプションでEnterを押すと

のようになるから、選択する。今回はlts(Long-Term Support)の長期安定版を選択した。
これで、aptでインストールできるようになった。

sudo apt update

これで仮想マシンに認識させて

sudo apt install mysql-community-server

打つと、

MySQLのroot用のパスワードを求められるので、仮想マシンのやつとは別々な強力なパスワードにする必要がある。なぜなら、仮にどちらかが突破されたとしてもパスワードが別々の場合被害の拡大を防ぎやすいからだ。
インストールが完了したら、確認してみよう。

sudo systemctl status mysql

cpserver@CP-server:~$ sudo systemctl status mysql
● mysql.service - MySQL Community Server
     Loaded: loaded (/usr/lib/systemd/system/mysql.service; enabled; preset: en>
     Active: active (running) since Tue 2025-11-25 20:04:32 JST; 30s ago
 Invocation: 550dce91738444b1a2051d6282859eb2
       Docs: man:mysqld(8)
             http://dev.mysql.com/doc/refman/en/using-systemd.html
   Main PID: 4395 (mysqld)
     Status: "Server is operational"
      Tasks: 35 (limit: 4620)
     Memory: 422M (peak: 437.8M)
        CPU: 4.833s
     CGroup: /system.slice/mysql.service
             └─4395 /usr/sbin/mysqld

11月 25 20:04:28 CP-server systemd[1]: Starting mysql.service - MySQL Community>
11月 25 20:04:32 CP-server systemd[1]: Started mysql.service - MySQL Community >

うん。大丈夫そうだ。
次に、DjangoがMySQLにアクセスするため、mysqlclientというpythonのライブラリをインストールする必要がある。ただし、mysqlclientは依存関係のあるパッケージが必要で以下をインストールする。

sudo apt install default-libmysqlclient-dev pkg-config 

ここでは、これらの依存関係のあるパッケージについての説明は省く。
これで、

pip install mysqlclient

をしてインストール。ようやくデータベースにアクセスできる準備が整った。
最後に、プロジェクト用のデータベースを作成しよう。

sudo mysql -uroot -p

mysqlのrootパスワードを求められるので入力。

(venv) cpserver@CP-server:~/workdir$ sudo mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.4.7 MySQL Community Server - GPL

Copyright (c) 2000, 2025, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

こうなれば成功。SQL内で、

CREATE DATABASE CP_DB;

と入力する。確認してみよう。

SHOW DATABASES;

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| CP_DB              |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.01 sec)

大丈夫そうだ。exitでデータベースからは出る。
ところで、用済みのファイルはrmコマンド(remove)で削除しておこう。

rm mysql-apt-config_0.8.36-1_all.deb

これでデータベースの設定は終わり。

Djangoの設定

CPsite/CPsite/にあるsettings.pyを編集する(cdで移動することをお忘れなく)

1 Debug設定を解除

- DEBUG = True
+ DEBUG = False

デバッグ設定のままだと、外部からプロジェクトのファイル構成が見られてしまうため。

2 ドメインの設定

- ALLOWED_HOSTS = []
+ ALLOWED_HOSTS = ["cp-server", "localhost", "127.0.0.1"]

nginxで指定したドメインとローカルホストを入れる。

3 データベースの設定

- DATABASES = {
-   'default': {
-        'ENGINE' :  'django.db.backends.sqlite3',
-        'NAME' :  BASE_DIR / 'db.sqlite3',
-    }
- }
+ DATABASES = {
+   'default': {
+       'ENGINE':   'django.db.backends.mysql',
+       'NAME':     'CP_DB',
+	    'USER':     'root',
+	    'PASSWORD': 'your-own-strong-password',
+	    'PORT' :    '3306'
+    }
+ }

使用するデータベースの設定を行う。
今回はデフォルトの【SQLite3】から【MySQL】に変更しているため、設定内容を反映させる。
パスワードはMySQLに使ったパスワード。

4 staticとmediaフォルダの設定

見やすくするために、nginxの静的ファイルとメディアファイル管理のURLをSTATIC_URL以下に追記する。STATIC_URL自体はデフォルトであるため書き換える。

STATIC_URL = '/static/'
STATIC_ROOT = '/usr/share/nginx/html/static'
MEDIA_URL = '/media/'
MEDIA_ROOT = '/usr/share/nginx/html/media'

実は、まだnginxに扱わせるstaticディレクトリとmediaディレクトリを作ってなかったりする。

sudo mkdir /usr/share/nginx/html/static
sudo mkdir /usr/share/nginx/html/media

上記の静的ファイルをDjangoプロジェクトに反映させるため、権限を少し変えよう。

sudo chown -R cpserver:www-data /usr/share/nginx/html/media
sudo chown -R cpserver:www-data /usr/share/nginx/html/static
sudo chmod -R 755 /usr/share/nginx/html/media
sudo chmod -R 755 /usr/share/nginx/html/static

ここで、chownコマンド(change owner)はファイルやディレクトリの所有者を変更するために使われる。-Rオプションをつけることで、そのディレクトリ内にあるすべてのファイルにも同じ操作をする。
[user]:[group]の順であるため、gunicornの設定ファイルなどから鑑みるとこれがベスト。
chmodコマンド(change mode)はファイルやディレクトリに対するアクセス権を変更するために使用される。数字は順に読み取り（Read: r）、書き込み（Write: w）、実行（Execute: x）の3種類であって権限設定は8進数で行われる。数字は左から順に所有者、所有者の属するグループ、その他で構成される。
ここで、manage.pyと同じディレクトリ内で

python3 manage.py collectstatic

を行う。もし、Djangoプロジェクト内で静的ファイルを編集した後、collectstaticをしなければウェブサイトには反映されないことも覚えておこう。
また、使用するデータベースも変更したため、Djangoプロジェクトにその旨を告知する必要がある。
manage.pyと同じディレクトリ内で

python3 manage.py makemigrations
python3 manage.py migrate

を行うとマイグレーションファイルを作成し、データベースに適用させる。

5 共通のhtmlファイルやcssファイルを認識させる

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
-       'DIRS': [],
+       'DIRS': [BASE_DIR / 'templates'],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

これをすると、異なるアプリで共通のhtmlファイルなどを作る際に便利。
同じ理由で、異なるアプリで共通のcssなどを管理する場合

+ STATICFILES_DIRS = [BASE_DIR / 'static']

をsettings.pyの一番下に追加する。

6 時間とか言語とか

- LANGUAGE_CODE = 'en-us'
- TIME_ZONE = 'UTC'
+ LANGUAGE_CODE = 'ja'
+ TIME_ZONE = 'Asia/Tokyo' 

合わせておいたほうが都合いいよね。(きれいだし)

indexページを作ろう

htmlの教材や授業でよく見るのはindex.htmlという名前だろう。これは、ウェブサイトにおいてトップページとして扱われるhtmlファイルで、いわば玄関なのだ。今回はそれを表示させて今回の記事は終わりとしよう。
さて、ここでdjangoプロジェクト内にアプリケーションを追加しよう。

python3 manage.py startapp home

とりあえず、homeアプリというものを作ってみた。treeを使ってみると

(venv) cpserver@CP-server:~/workdir/CPsite$ tree -L 3
.
├── CPsite
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-313.pyc
│   │   ├── settings.cpython-313.pyc
│   │   ├── urls.cpython-313.pyc
│   │   └── wsgi.cpython-313.pyc
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── home
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
└── manage.py

生成されていることがわかる。
__init__.py:導入参照

admin.py:djangoの管理サイト (Admin Site) に、アプリケーションのモデルを登録するためのファイルだ。ここにモデルを登録することで、開発中にデータベースの内容をブラウザ経由で簡単に確認・操作できるようになる。

apps.py:アプリケーションの設定を定義するファイル。アプリケーションのフルネームや設定クラスなどが含まれており、Djangoがアプリを認識し、設定をロードするために使用する。

migrations
モデルの変更をデータベーススキーマに適用するため使用されるマイグレーションファイルを格納するディレクトリ。

models.py
アプリケーションのデータ構造、すなわちモデルを定義するファイル。モデルは、アプリケーションが扱うデータを表現するPythonクラスであり、データベースのテーブルに対応します。モデルを定義することで、SQLを直接書かなくても、Pythonコードを通じてデータベースとやり取りできるようになる。

tests.py
アプリケーションのテストコードを記述するファイル。ビューやモデル、カスタムロジックなどが期待通りに動作するか検証するためのユニットテストや機能テストを記述する。

views.py
アプリケーションのロジックを定義するファイル。ユーザーからのHTTPリクエストを受け取り、適切な処理（例: データベースからのデータ取得、計算、テンプレートのレンダリング）を行い、HTTPレスポンスを返すビュー関数またはビュークラスを記述する。

さて、アプリを作成したらまずやらなければならないことがある。
cdでCpsite/CPsite/に行き、settings.pyを開き、以下のように編集する。
#はコメントを表すので、その行の#以降は気に入らなければ削除して良い。

CPsite/CPsite/settings.py

...
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'home', # <- homeアプリを認識させる
]
...

これを行わないと、django側がhomeアプリを認識しない。アプリを作成した後は必ず行うこと。
次に行うべきなのは、urls.pyを開く。

CPsite/CPsite/urls.py

...
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('home.urls')), # <-homeアプリのURLを追加
]
...

これをしておくと、各アプリでurls.pyを定義したときに各ページをアプリごとにまとめられて便利だ。
今回は、index.htmlを表示させたいため、以下の操作を行う。
homeディレクトリにcdで移動し、nanoでviews.pyを編集し以下のようにする。

CPsite/home/views.py

from django.shortcuts import render

def index(request):
    # クライアント（ブラウザ）から送られてきた HTTP リクエストを受け取り、
    # "home/index.html" というテンプレートを使って HTML を生成して返すビュー関数。
    return render(request, "home/index.html")  # テンプレートをレンダリングしてレスポンスを返す

nanoでurls.pyを作成、編集する。

CPsite/home/urls.py

from django.urls import path
from . import views
app_name = 'home'  # URL の名前空間。{% url 'home:index' %} のように参照できる

urlpatterns = [
    # URLパターンの一覧
    path('', views.index, name='index'),  # ルートURLにアクセスしたとき indexビューを呼ぶ
]

実際に簡単なページを作成してみよう。
CPsite/home内にtemplatesディレクトリを作成する。

mkdir templates

templates内に移動し、さらにmkdir homeを行う。なぜなら、djangoのテンプレートローダーは、アプリ名ディレクトリを考慮せずテンプレートを探しにいくため、名前が同じ場合に衝突が発生するからだ。ここで、アプリ名のディレクトリを作成しておくことで、違うアプリの中にある同じファイル名同士は衝突を起こさず識別できるというわけだ。
nanoでindex.htmlを編集する。

CPsite/home/templates/home/index.html

<!DOCTYPE HTML>
<html lang="ja">
<head>
	<meta charset="UTF-8">
	<title>ホーム</title>
</head>
<body>
<h1> はじめまして! </h1>	
</body>
</html>

変更を完了したら、今度はそれをnginxに読み込ませる必要がある。
そのため、gunicornを更新させればnginxに渡してくれる。

sudo systemctl restart gunicorn

これで、つぎの節に行こう。

成果を見てみよう

の左下の狐のブラウザ「firefox」を開こう。
http://<your_VMname>(仮想マシン名)にアクセス
(私の場合はhttp://cp-server)

できた！これで、djangoからrunserverしなくても、nginxの持つサーバーの名前にアクセスすれば、htmlファイルが返ってくるようになったね。大体のシーケンス図を書いてみよう。

マーメイド図的には

今日はおやすみ！