この投稿では、Apache2.4 のVirtual Hostを使って、1つのIPアドレスで、複数のサブ・ドメインを使う時の２つの記述方法と注意点を記載しています。
特に、wwwつき、なしを管理する場合は、有効です。 （この投稿では書きませんが、DNSには、全てのサブドメインに対して、使用するIPアドレスをAレコードに登録するなどの作業を忘れずにしてくださいね。）
*自分が使っているDNS管理会社の管理画面です。
個別のhtmlファイルをそれぞれのサブドメインに設置するとか、WordPressのブログに別のサブドメイン名を使いたいといったようば場合は、この設定で充分です。
但し、何等かのアプリをプログラムで作成して、Frameworkを使ってルーティングさせたい場合の設定は、次回以降の投稿を参考にしてください。
◇Virtual Hostとは
1台のサーバーにインストールしたApacheを使って、複数のドメインでサービスを行うための仕組み。
Apache 2.4 のconf 設定ファイルは
/etc/httpd/conf/ httpd.conf
という、最初に読み込まれるファイルあり、
/etc/httpd/conf.d や
/etc/httpd/conf.modules.d 等の
それぞれのディレクトリに、個別のサブ・ドメインに対応したバーチャルホストの設定が書かれています。
[root@ /]# ls -a etc/httpd/
. .. conf conf.d conf.modules.d logs modules run
Apache 2.4 の設定ファイルは /etc/httpd/conf/httpd.conf というファイルが大元となっており、個別のモジュールなどの設定は /etc/httpd/conf.d や /etc/httpd/conf.modules.d ディレクトリに設定が保存されています。 httpd.conf から、 conf/conf.d や conf/conf.modules.d フォルダの設定を Include するようになっています。
（参考：conf.modules.d ディレクトリやconf.d ディレクトリの全てを読み込めと書いてあるのが確認できます。）
[root@ /]# ls -a etc/httpd/
. .. conf conf.d conf.modules.d logs modules run
[root@ conf]# pwd
/etc/httpd/conf
[root@ conf]# vi httpd.conf
Include conf.modules.d/*.conf
IncludeOptional conf.d/*.conf
従って、conf.d ディレクトリの配下に、任意の名前のconf ファイルを作って管理することが可能。
勿論、httpdに直接、記載することも可能ですが、 多くのサブドメイン（ホスト名）を利用する場合などは、別ファイルにした方が分かり易いと思います。
(自分は、conf.d/ ディレクトリの配下に、サブホスト名をファイル名につけた.conf ファイル を作成して管理します。）
（設定）
1. 大元のhttpd.confに直接編集する必須の記述
Virtual Hostを使用することの宣言を書きます。作業は、デフォルトの記述でコメントアウトになっているホスト名を記述している箇所が、きちんとコメントアウトされているか確認。
次に、バーチャル・ホストを使うことを宣言する１行を書きます。
（デフォルトのファイル保管場所）
/etc/httpd/conf/httpd.conf
1) コメントアウトの確認
（修正前）
ServerName www.example.com:80
↑ Defaultではコメントアウトになっているので、特別に設定を変えていなければ修正不要。
(修正後：コメントアウト）
#ServerName www.example.com:80
2) 名前ベースの VirtualHost の待受けをすることを宣言）
記載する場所はどこでも可だが、とりあえず 'Listen 80'の下に書く。
NameVirtualHost *:80
2. 個別の.confファイルの記述
次に、個別のバーチャルホストの設定をconfファイルに記述します。
/etc/httpd/conf.d/virtual.confの作成・編集
(virtual.conf のvirtualは任意につけてください。以下、このconfファイルに記載する内容です。）
方法１） ServerAliasを使う方法
Virtual Hostには、DocumentRootとServerNameが必須の記載事項だが、この方法だと、何度も同じような記載をしてくても良いので簡易。 ただし、Server Aliasのサブホスト（ホスト名）のDocument Rootは、オリジナルのDocument Rootと一緒してしまう擬似的な方法。
記載している内容は、
・www.mossymob.tk のアクセスは、mossymob.tk と同じ(alias)
と指定しているだけ。
この為、アップロードするコンテンツを、サブ・ドメイン（ホスト名）毎に管理したい場合は、方法２の方が便利。 又、Let's Encryptを使ってSSLに対応する場合、このメソッドは機能しない。
（実際の virtual.confの記入例）
[root@ip2h3wsy httpd]# ls -a
. .. conf conf.d conf.modules.d logs modules run
[root@ip2h3wsy conf.d]# touch virtual.conf
[root@ip2h3wsy conf.d]# vi virtual.conf
< VirtualHost *:80>
ServerAdmin root@mossymob.tk
DocumentRoot /var/www/html
ServerName mossymob.tk
ServerAlias www.mossymob.tk <- wwwはServer Aliasで対応できる。
ServerAlias www.mossymob.net <- 複数のドメインでも、Server Aliasで対応できる。
CustomLog /var/www/html/access.log common <- ログは検証時のみ。必要なら。
ErrorLog /var/www/html/error.log <- apacheのパフォーマンスが顕著に悪くなる。
< /VirtualHost>
方法２ 順番に個別に記載する
（Virtual Hostを複数記入する場合の例）
#1つめのサイト
<VirtualHost *:80>
ServerName mossymob.tk
DirectoryIndex index.html index.php
AddDefaultCharset UTF-8
DocumentRoot /var/www/html/
<Directory "/var/www/html/">
AllowOverride All
Options FollowSymLinks -Indexes
</Directory>
</VirtualHost>
#2つ目のサイト
<VirtualHost *:80>
ServerName www.mossymob.tk
DirectoryIndex index.html index.php
AddDefaultCharset UTF-8
DocumentRoot /var/www/html/
<Directory "/var/www/html/">
AllowOverride All
Options FollowSymLinks -Indexes
</Directory>
</VirtualHost>
#３つ目のサイト
<VirtualHost *:80>
ServerName uslife.mossymob.tk
DirectoryIndex index.html index.php
AddDefaultCharset UTF-8
DocumentRoot /var/uslife/html/ <-アクセスがあった時に最初に表示するファイルを格納するドキュメント・ルートは自由に指定してよい。
<Directory "/var/favname/html/">
AllowOverride All
Options FollowSymLinks -Indexes
</Directory>
</VirtualHost>
など。
* < VirtualHost *:80></VirtualHost>の内容は、別ファイルを作らずに、httpd.confファイルの最後に記載しても良い。
変更したらシステムのリロードを忘れずに。
# systemctl reload httpd
追記）
wsgiを使用している場合、並列に書くだけでは、httpdがリロードさえ出来ないエラーになる、
という事が判明しました。 これを避けるための詳細な記事は、以下で解説。
【 複数のサブドメインを管理しているサーバで、wsgiを使う時のVirtual Hostの書き方 】
<Directory> ディレクティブで指定できる事項。
| CustomLog | アクセスログ |
| ErrorLog | エラーログ |
| AddHandler | CGIスクリプトを使用するかしないか |
| AllowOverride | .htaccessによる設定変更を有効にするかどうか |
| IfModule | モジュールが存在する時に処理される |
| RewriteEngine | RewriteEngineをONにするかOFFにするか |
| RemoveHnadler | ファイル拡張子に関連付けされたハンドラをすべて解除する |
| RewriteCond | 書き換えの条件を指定する。条件に一致したときだけ書き換え |
| RewriteRule | 書き換えのルール。パターンに一致した値を置換する |
◆ Daemon Mode (Single Application)
The preferred way of setting up mod_wsgi is to run each WSGI application in its own daemon process group. This is called daemon mode. A typical configuration for running a WSGI application in daemon mode would be:
① WSGIDaemonProcess myapp
② WSGIProcessGroup myapp
③ WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /some/path/project/myapp.wsgi
<Directory /some/path/project>
Require all granted
</Directory>
The ① WSGIDaemonProcess directive defines the daemon process group.
The ②WSGIProcessGroup directive indicates that the WSGI application should be run within the defined daemon process group.
As only the single application is being run within the daemon process group, the
③ WSGIApplicationGroup directive is also being used. When this is used with the %{GLOBAL} value, it forces the WSGI application to run in the main Python interpreter context of each process.
This is preferred in this scenario as some third party packages for Python which include C extensions will not run in the Python sub interpreter contexts which mod_wsgi would use by default. By using the main Python interpreter context you eliminate the possibility of such third party packages for Python causing problems.
To modify the configuration for this scenario to use a Python virtual environment, all you need to do is add the python-home option to the WSGIDaemonProcess directive resulting in:
WSGIDaemonProcess myapp python-home=/usr/local/venvs/myapp
0 件のコメント:
コメントを投稿