Ubuntu 環境へ Django で作った WEB アプリケーションをデプロイする ② 【サーバとは何か】

エラーがでまくったので結局サーバーサイドの基礎知識を得るところから始めました。
ここから一歩歩くごとにエラーが出ました。

: Ubuntu 環境へ Django で作った WEB アプリケーションをデプロイする ① 【ローカル > サーバ】
ConoHa VPS の環境構築【ログイン設定】上記で構築した VPS に Django で作成したアプリケーションをデプロイしていきます。【ローカル】ローカルの設定 Djangoの設定ファ ...

こちらは上記の記事の続きです。

サーバの概要

このページは「サーバとは何か」というのが一貫したテーマになってきます。

実際のところ私はここにくるまで「サーバはどこかにあるコンピュータ」という認識しかありませんでした。

今までであればこの認識で何の問題も起きなかったんですが、
Django をデプロイしていくにあたってはこの認識では一歩も前に進めませんでした。

サーバとは

利用者の要求（リクエスト）に対して、それに応答したデータを提供するコンピュータやプログラムのことを“サーバー”と呼んでいます。
サーバーとは？種類や用途について簡単に解説

サーバを一言で表すと上記の文章になります。

クライアントからきたリクエストに対してレスポンスを返すものをサーバと呼びます。

ここではリクエストを受け取り、レスポンスを返す仕組みを Ubuntu ( Linux ) に構築することがゴールとなります。

Web サーバ

サーバにはいくつか種類があります。

今回作っていくのは Webサーバに分類されるサーバで、リクエストが来た際にそれに対応するhtml や css 、JavaScript など、Web ページに関するデータを返すサーバです。

この Webサーバを Nginx （エンジンエックス）というソフトウェアで作っていきます。
Django はこの Nginx でWebサーバを作ることが主流です。

ファイアウォールとポート

VPS をレンタルしたデフォルトの状態ではファイアウォールが機能していないはずです。
アクティブになっていた場合、ポートが解放されていないため Tera Term などでアクセスできません。

ステータスを確認するには下記のコマンドです。

sudo ufw status

ファイアウォールを起動します。

sudo ufw enable

ポートを開放します。

sudo ufw allow 80
sudo ufw allow 22

これでファイアウォールを起動した状態で http と ssh でのやりとりができます。

ファイアウォール関連のコマンドは下記です。

ステータスの確認	sudo ufw status
起動	sudo ufw enable
停止	sudo ufw disable
リロード	sudo ufw reload
リセット	sudo ufw reset
ルールの確認	sudo ufw status numbered
ポートの解放	sudo ufw allow ポート番号
ポートの削除	sudo ufw delete ルール番号

Ubuntu ファイアウォールの設定と確認の仕方（初心者向け）

Tera Term で接続できなくなった場合

ファイアウォールを起動して 22番ポートを解放せずに Tera Term などの接続を切った場合は接続ができなくなります。

Tera Term などの SSH 接続は 22番のポートで接続しますが、そのポートがファイアウォールでブロックされているためです。
こうなった場合はレンタルサーバのコンソールから入って 22番ポートを開放します。

Nginx のインストール

Ubuntu へのインストールは下記のコードでインストールができます。

sudo apt-get install nginx

CentOS などはインストールのコマンドが違います。下記を参照してください。

インストール | NGINX WIKI

インストールされた Nginx のバージョンを確認するには下記のコマンドです。

nginx -v

nginx version: nginx/1.18.0 (Ubuntu)

私の場合は 1.18.0 の Ubuntu の環境でサーバを構築していきます。

インストールの確認

インストールが終わった段階でインターネットブラウザからレンタルしている IP アドレスにアクセスすると Nginx が起動していることがわかります。

http://○○○.○○○.○○○.○○○/

この表示がでていればインストールは成功しています。

Welcome to nginx! の html ファイル

下記のフォルダにこのページを表示するための html ファイルが格納されています。

cd /var/www/html

index.nginx-debian.htmlの中身を見てみます。

vi index.nginx-debian.html

index.nginx-debian.html の中身

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

先ほどのページのコードになっています。これを書き換えると表記も変わります。

つまり、現在 Nginx は既に Web サーバとして機能しており、レンタルしている IP アドレスにリクエストが来た場合にこの html ファイルを返しているということです。

まずはここの仕組みをみていきます。
現在 Nginx はどうやってリクエストを受け取り、どうやってレスポンスを返しているのでしょうか。

設定フォルダの構成 ①

Nginx の設定に関するフォルダは下記の場所にあります。

cd /etc/nginx

この中にnginx.confというファイルがあります。これが Nginx の設定ファイルです。

nginx.conf

vi /etc/nginx/nginx.conf

nginx.conf の中身

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}


#mail {
#       # See sample authentication script at:
#       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#       # auth_http localhost/auth.php;
#       # pop3_capabilities "TOP" "USER";
#       # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#       server {
#               listen     localhost:110;
#               protocol   pop3;
#               proxy      on;
#       }
#
#       server {
#               listen     localhost:143;
#               protocol   imap;
#               proxy      on;
#       }
#}

ただ、このファイルを直接編集することは推奨されていません。

代わりに下記の2つのフォルダを利用して設定していきます。

available と enabled

cd /etc/nginx/sites-available

cd /etc/nginx/sites-enabled

この2つのフォルダには両方とも default というファイルが入っています。
拡張子がないのでわかりづらいですが、この default はフォルダではなくファイルです。

ls /etc/nginx/sites-available
ls /etc/nginx/sites-enabled

Tera Term で見た場合、sites-enabled の方は水色で表示されています。
これはシンボリックリンクを表しています。
シンボリックリンクは Windows でいうところのショートカットです。

図で見ると下記のようになっています。

/etc/nginx
 │ 
 ├─ sites-available 
 │          │ 
 │          └─ default  <- 設定ファイルの本体
 │ 
 └─ sites-enabled 
            │ 
            └─ default  <- シンボリックリンク

sites-available には設定ファイルが入っていて、sites-enabled にはそのファイルのシンボリックリンク（ショートカット）が入っている、ということになります。

default ファイルの中身の確認

sites-available に入っている default ファイルの中身を見てみます。

vi /etc/nginx/sites-available/default

default の中身

##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or WordPress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##

# Default server configuration
#
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}
}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#       listen 80;
#       listen [::]:80;
#
#       server_name example.com;
#
#       root /var/www/example.com;
#       index index.html;
#
#       location / {
#               try_files $uri $uri/ =404;
#       }
#}

コメント部分が多いのでコメント部分を省いて表示してみます。

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                try_files $uri $uri/ =404;
        }
}

結論からいくと上記のコードは
HTTP（80番ポート）でリクエストを受けた場合、ウェルカムページの html ファイルを返すという内容になっています。

サーバの定義は リクエストに対応するレスポンスを返す ことでした。

つまり、上記数行のコードがサーバを定義するもの　と言えます。

では、この default ファイルが具体的にどう書かれているのかを解説していきます。

nginx連載4回目: nginxの設定、その2 - バーチャルサーバの設定

server コンテキスト

server {
}

一番大枠のやつです。コンテキストは文脈を指します。

3.1.1 コンテキスト

サーバに関する設定は上記のserver{}の中に記述していきます。

ディレクティブ

この設定ファイルにはいくつかのディレクティブが記載されています。
ディレクティブとは指示のことです。用途は違いますが、意味合いとしてはコマンドとかに近い気がします。
ディレクティブの末尾には「 ; 」セミコロンが必要です。

Nginxの文法の基本であるディレクティブの意味についてゆるーく説明

listen ディレクティブ

listen 80 default_server;
listen [::]:80 default_server;

listen ディレクティブはポート番号を設定します。
このサーバが何番のポートで待ち受けるかです。

上記のコードでは 80番のポートが指定されています。

listen ディレクティブの引数には default_server が用意されています。
default_server は IP アドレスやドメインのリクエストが飛んできたとき、どのサーバに接続するかの優先度に関わる引数です。
この default_server は優先度についての部分で後述します。

root / index ディレクティブ

どのデータを返すかを指定します。

root /var/www/html;
index index.html index.htm index.nginx-debian.html;

ここは Welocome ページの HTML ファイルが指定されています。先ほど確認した下記のページの html ファイルです。

index ディレクティブには引数が 3つあります。

index index.html index.htm index.nginx-debian.html;

左から順にファイルを調べていき、存在すればそのファイルをリダイレクトし、存在しなければ次の引数のファイルを探す、という流れで調べていきます。

root ディレクティブには index.nginx-debian.html ファイルしか存在しないため、3つ目の index.nginx-debian.html が内部リダイレクトされます。

cd /var/www/html

vi /var/www/html/index.nginx-debian.html

内部リダイレクト

普通のリダイレクトはレスポンスコードに301や302を、Locationヘッダフィールドにリダイレクト先のURIを指定して返し、クライアントはそのURIに対して再びリクエストを送ります。これとは別に内部リダイレクトというものがあります。これは、レスポンスコードに301や302を指定せずに、内部的にURIのパスの書き換えを行い、その結果のページの内容を返します。クライアントから見るとリダイレクトしているようには見えません。nginxではこのような内部リダイレクトがよく使われます。
次のセクション以降で説明するindexディレクティブ、error_pageディレクティブ、tri_filesディレクティブではこの内部リダイレクトが使われます。内部リダイレクトではリダイレクト先のパスに対して毎回locationディレクティブの評価が行われます。
nginx連載5回目: nginxの設定、その3 - locationディレクティブ

server_name ディレクティブ

server_name _;

ここには本来ドメイン名が入ります。ドメイン名を入れる場合は下記のように記述します。

server_name http://hoge.com;

上記のコードでは http://hoge.com のリクエストを待ち受け、hoge.com が来た際にウェルカムページの html を返す内容になります。

コードに記載されているserver_name _;を指定した場合はすべてのドメイン名を対象にします。
このコードの内容は 80番ポートに入ってきたすべてのドメインに対してウェルカムページの html を返しています。

また、ここにはドメイン名ではなく IP アドレスを入れることもできます。

server_name レンタルしている IPアドレス;

あるいは

server_name $hostname;

$hostname にはホストの IP アドレスが入りますので、上記の二つは同じ意味になります。

location コンテキスト

location / {
        try_files $uri $uri/ =404;
}

location コンテキストは URI （ここでは URL と捉えても問題ないです）のパス毎の設定を行えるコンテキストです。
この URI の時はここ、この URI がきたときはここ、というように複数の場合を設定することができます。

URIとは？「URL」と「URI」の違いを解説！

try_files はファイルを探すディレクティブです。
try_files $uri $uri/ =404;
上記のコードはファイルが存在しない場合に 404 のステータスコードを返す、という意味になります。

nginxのtry_filesわかりにくすぎ問題

設定フォルダの構成 ②

ここまで解説してきたのは下記のディレクトリです。

cd /etc/nginx

/etc/nginx
 │ 
 ├─ nginx.conf          <- メインの設定ファイル
 │ 
 ├─ sites-available 
 │          │ 
 │          └─ default  <- 設定ファイルの本体
 │                         先ほど解説したファイルです。
 │  
 └─ sites-enabled 
            │ 
            └─ default  <- シンボリックリンク

他にもファイルやフォルダが入っていますが今のところ関係ないので上記の部分にのみ絞ってみていきます。

available と enabled が存在するワケ

では、なぜこの dafault ファイルが sites-available に入っていて
そのシンボリックリンクが sites-enabled に入っているか、という部分を解説していきます。

アプリケーションとサーバ

基本的にはサーバごとに一つの設定ファイルを用意して運用していきます。

例えば、公開したいアプリケーションが3つあったとします。

application_A
application_B
application_C

これらのアプリケーションには多くの場合、それぞれ別のサーバが必要です。

application_A 　 - 　server_A
application_B 　 - 　server_B
application_C 　 - 　server_C

アプリケーションA には専用のドメインを設定し、専用の html を返したいし、アプリケーションB にも個別のドメインを設定し、B専用の html を返したいのが普通の考え方だと思います。

これら 3つのサーバの設定をメインの nginx.conf に記載しても動くのは動きます。
ただ、3つだけならまだいいんですが、例えばレンタルサーバなどの場合は数千というサーバを扱うことになるため、nginx.conf で一括管理することは現実的ではありません。

この問題を sites-available と sites-enabled を利用して回避しています。

sites-available と sites-enabled

sites-available には設定ファイルの本体を置き、設定を有効にするファイルのみ sites-enabled にシンボリックリンクを置きます。
つまり、 sites-enabled にシンボリックリンクがある設定ファイルのみ有効になります。

sites-available	設定ファイルの本体設定ファイルを入れていく。
sites-enabled	設定ファイルのシンボリックリンクここにシンボリックリンクを置いて初めて設定が反映される。

nginx.conf の内容を見てみます。

vi /etc/nginx/nginx.conf

62行目に下記のコードが記されています。

include /etc/nginx/sites-enabled/*;

これは sites-enabled の中にあるファイルを含める、というコードです。
これが記述されているため nginx.conf から sites-enabled に接続され、その中にあるシンボリックリンクから sites-available に繋がります。

設定ファイルの全体像

/etc/nginx
 │ 
 ├─ nginx.conf           <- メインの設定ファイル　
 │ 　　　　　　　　　　　　   include /etc/nginx/sites-enabled/*;
 │ 
 ├─ sites-available    
 │          │ 
 │          ├─ server_0  <- 〇 読み込まれる
 │          │ 
 │          ├─ server_1  <- 〇 読み込まれる 
 │          │ 
 │          ├─ server_2  <- ☓ 読み込まれない 
 │          │ 
 │          └─ default   <- ☓ 読み込まれない 
 │ 
 │ 
 └─ sites-enabled        <- nginx.conf はここに接続される
            │ 
            ├─ server_0  <- available の本体に接続
            │ 
            └─ server_1  <- available の本体に接続

静的ファイルを表示してみる

では、実際に設定ファイルとテスト用の html ファイルを用意して任意のサーバを構築してみます。

html ファイルの作成

今回は/usr/share/nginx/htmlの場所に「 test_html.html 」というhtml ファイルを作り、この IPアドレスに接続した際にこの test_html.html を返すようにしてみます。

html ファイルの作成

cd /usr/share/nginx/html

検証用の html ファイルを上記の場所に作成します。

sudo touch test_html.html
sudo vi test_html.html

html ファイルの編集

テスト用なので下記のような内容にしてみます。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Welcome to nginx!</title>
    <style>
        body {
            width: 35em;
            margin: 0 auto;
            font-family: Tahoma, Verdana, Arial, sans-serif;
        }
    </style>
</head>
<body>
    <h1>テスト用の html</h1>
</body>
</html>

設定ファイルの作成

test_server.conf という設定ファイルを作ります。

設定ファイルの作成

cd /etc/nginx/sites-available
sudo touch test_server.conf
sudo vi test_server.conf

現在は下記のような構成になっています。

/etc/nginx
 │ 
 ├─ nginx.conf  
 │ 
 ├─ sites-available 
 │          │ 
 │          ├─ test_server.conf <- 今作ったファイル
 │          │ 
 │          └─ default  
 │  
 └─ sites-enabled 
            │ 
            └─ default

設定ファイルの編集

server {
    listen 80 default_server;
    server_name _;
    root /usr/share/nginx/html;
    index test_html.html;
}

最低限のものにしています。

80番ポートで待ち受け、やってきたリクエストに対して
/usr/share/nginx/html/test_html.htmlを返します。

シンボリックリンクの作成

シンボリックリンクの作り方は下記です。

sudo ln -s ファイル名 リンク名

今回の場合は下記のように記述します。

sudo ln -s /etc/nginx/sites-available/test_server.conf  /etc/nginx/sites-enabled/test_server.conf

シンボリックリンクの削除

default のシンボリックリンクを削除しておきます。

サーバはいくらでも建てることができます。その際、読み込みの優先順位があります。
default は存在するだけでほかのサーバとバッティングする可能性があり、邪魔になります。
そのため defaoult のシンボリックリンクを下記のコマンドで削除しておきます。

sudo unlink default

default ファイルにはコメントで普通はこのファイルを使わない旨が記載されています。
ファイルを開いて確認してみます。

vi /etc/nginx/sites-available/default

８行目です。

In most cases, administrators will remove this file from sites-enabled
ほとんどの場合、管理者はこのファイルをサイト対応から削除します

とあります。安心して削除して大丈夫です。

ディレクトリ構成

これで関係するディレクトリの構成は下記のようになっています。

/etc/nginx
 │ 
 ├─ nginx.conf  
 │ 
 ├─ sites-available 
 │          │ 
 │          ├─ test_server.conf <- 設定ファイル
 │          │ 
 │          └─ default  
 │  
 └─ sites-enabled 
            │ 
            └─ test_server.conf <- シンボリックリンク 

/usr/share/nginx/html
 │  
 └─ test_html.html

default のシンボリックリンクを削除しただけで、本体の設定ファイルはそのまま残っています。

これで ngin.conf → test_server → test_html へ接続されるようになっています。

Nginx のリロード

変更した設定を反映させるには一度 Nginx のリロードを行います。
下記のコマンドが Nginx のリロードです。

sudo systemctl reload nginx.service

ついでに他のコマンドもまとめておきます。

起動	sudo service nginx start
状態確認	sudo systemctl status nginx.service
停止	sudo systemctl stop nginx.service
設定ファイルの再読み込み	sudo systemctl reload nginx.service
Linux 起動時に自動で起動	sudo systemctl enable nginx.service
自動起動の解除	sudo systemctl disable nginx.service

リロードして再度 IP アドレスを Chrom などで開くと表示がかわっているはずです。

リロードでエラーが発生する場合

私の場合はリロードでエラーが発生しました。
出ていたエラー内容が下記です。

nginx.service is not active, cannot reload.

Nginx が起動していないのでリロードできません、と言われていますが、ウェルカムページは問題なく表示できているので起動していると思われる状況でした。

nginx が起動しない・動かない場合の対処方法と確認ポイント

設定ファイルの不備の確認

下記のコードで設定ファイルに不備がないか確認できます。

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 lsof -i -P -n | grep LISTEN

Apache を使用されている場合、80番ポートが競合してしまっている可能性があるそうです。
80番ポートの使用を停止してからリロードしてください。

ファイアウォールを調べる

80番ポートが解放されていない可能性もあります。

sudo ufw status

これで 80番がない場合は下記で 80番ポートを開放します。

sudo ufw allow 80

サーバを再起動させる

私の場合はサーバを再起動することで無事リロードできるようになりました。

ConoHa VPS の場合は VPS のアカウントページのトップにサーバの再起動ボタンがあります。

ドメインを取得して WEBサーバで利用する

ドメインを利用してアクセスします。

IPアドレスは 192.0.2.0 のように 8ビットが4つ連なる形で表記されます。
これに対してドメインは普段目にする http://expample .com の expample.com の部分です。

詳しくは参考動画を置いておきます。

ドメインの取得

今回は Xserver Domain でドメインを取得して WEBサーバで利用していきます。
私はテスト用に 1年1円で借りられるものを取得しました。
2年目から普通にお金が発生しますので注意してください。
1円のものを銀行振込で支払っておけば停止するのを忘れても自動で更新される心配がありません。

DSNサーバの設定

ここから Xserver Domain の公式ドキュメントのまま進めていきます。

ネームサーバーの設定

XServer Doman に設定して進めてください。

DNSレコードの設定

DNSがインターネットの「電話帳」のようなものだと述べました。しかし、より具体的に説明すると次のとおりです。
・ネームサーバーは、電話帳そのものです。
・ DNSレコードは、電話帳の個々の項目です
ネームサーバーの概要と重要である理由について

DNSレコードの編集

左のメニューの DNSレコード設定 > DNS レコード設定を追加する
へ進みます。

これは上記の例文でいうところの、電話帳の追記です。
電話帳に新しい人の名前と電話番号を追記するイメージです。

上記の設定で、ホスト名でアクセスした際に内容の項目に記載した IPアドレスに接続する設定になります。

Nginx の設定ファイルの編集

上記の DNSサーバの設定で取得したドメインと IPアドレスが紐付けられました。

server {
    listen 80 default_server;
    server_name example.com;
    root /usr/share/nginx/html;
    index test_html.html;
}

server_name に取得したドメインを記載します。

これで example.com にアクセスすると先ほどの html が表示されるはずです。

この時、ウェブページの描画までの流れは下記のようになっています。

クライアント
Xserver Domain の example.com
ConoHa VPS の IPアドレス「 192.0.2.0 」
Nginx の nginx.conf
sites-enabled の test_server.conf のシンボリックリンク
sites-available の test_server.conf 本体
test_html.html
クライアントに test_html.html を返す
クライアントのWEBブラウザが描画

といった流れになります。

③へ続きます。

: Ubuntu 環境へ Django で作った WEB アプリケーションをデプロイする ③【APサーバ】
上記の記事の続きです。前回は VPS の中に Nginx を使用して Web サーバを構築し、リクエストを送るとレスポンスが返ってくるところまで行いました。 WEB 3層構成目的は題名の通り、Dj ...