Docker を試してみる

GCE (Google  Computer Engine) の無料枠でいろいろ練習してみることにする。関心があったけどこれまで面倒で触れてなかった CentOS7 と Docker。今は CentOS6 を使ってるけどそろそろ次のことも考えて CentOS7 の準備もしておかないといけない。Docker は使いこなせるようになったらインストールとかサーバ移行とかテストとか楽になるんだろうか。

GCE で CentOS7 の準備

インスタンスの作成とSSHでログインできるようにするところは省略。とりあえず yum で update しておく。

$ sudo yum update
$ sudo shutdown -r now

Docker のインストール

参考:

• Qiita:  CentOS7にDockerをインストールする,
• Docker公式: Get Docker CE for CentOS

古い docker がインストールされていないことを確認（インストールされてたら削除する）。
$ sudo yum list installed | grep docker


必要なパッケージをインストール。
$ sudo yum install -y yum-utils device-mapper-persistent-data lvm2

リポジトリ追加。
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Docker CE をインストールする。CE ってなんだ？ああ、Common Edition か。
$ sudo yum install docker-ce

Docker を起動する。
$ sudo systemctl start docker

確認する。
$ sudo docker run hello-world

Docker Compose のインストール

参考:

• Qiita: CentOS7.3にDocker Composeまでインストール
• Docker公式: Install Docker Compose

Docker Compose のダウンロードとインストール。公式だとcurl でダウンロードした実行ファイルを直接 /usr/local/bin に放り込んでる。引くわ。
$ curl -L https://github.com/docker/compose/releases/download/1.18.0/docker-compose-`uname -s`-`uname -m` -o ./docker-compose
$ sudo install docker-compose /usr/local/bin/

バージョンの確認。
$ docker-compose --version

自分自身を docker グループに追加

docker コマンドを直接実行できるように docker グループに自分を追加しておく。次回ログイン時から有効になる。
$ sudo gpasswd -a $USER docker

composer の更新

mediawiki のいくつかの拡張は composer を使用している。composer が何者かあまり意識してなかったけど、PHP のパッケージ管理ツールということらしい。

composer がどういう状態になっているかサーバを確認してみると mediawiki のホームディレクトリにインストールされていた。

まずはインストールされているパッケージの一覧を確認してみる。 composer show -i で確認できるとのことだ。PHP 自体が scl の管理下にあるのでコマンドラインが長い。

$ sudo -u apache scl enable rh-php56 -- php composer.phar show -i
Warning: This development build of composer is over 60 days old. It is recommended to update it by running "composer.phar self-update" to get the latest version.

パッケージの一覧は確認できたが warning も表示された。composer がちょっと古いらしい。

composer のバージョンは -V で確認できる。

$ scl enable rh-php56 -- php composer.phar -V
Warning: This development build of composer is over 60 days old. It is recommended to update it by running "composer.phar self-update" to get the latest version.
Composer version 1.2-dev (f0f932fca403267a141e91f9262ab649b95b2ed9) 2016-09-10 10:52:23

なるほど。

調べると composer の現行バージョンは 1.5.5 だったが、いきなりあげて動かなくなったら困るので 1.2 系列の最終バージョンで様子を見ることにした。特定バージョンに更新するには self-update のあとにバージョンを指定すれば良いらしい。

$ sudo -u apache scl enable rh-php56 -- php composer.phar self-update 1.2.4
Updating to version 1.2.4 (stable channel).
    Downloading: 100%
Use composer self-update --rollback to return to version f0f932fca403267a141e91f9262ab649b95b2ed9

パッケージ更新前に --dry-run で更新対象パッケージとバージョンを確認しておく。

$ sudo -u apache scl enable rh-php56 -- php composer.phar --dry-run update

で、バージョン確認後、問題なさそうなので更新。

$ sudo -u apache scl enable rh-php56 -- php composer.phar update

幸いサーバにはトラブルなかった模様。

MediaWiki 更新

MediaWiki を 1.26.3 から 1.27.1 へ更新した。
展開したファイルをコピーしてインストールディレクトリの maintenance ディレクトリへ移動、update.php を実行したところ composer が古いので update しろとのメッセージが出てしまう。

MediaWiki インストールディレクトリに移動して php composer.phar update を実行してはみたものの、エラーが出て動かない。

この状態で MediaWiki 本体は動くのだけれど、composer に依存してる chameleon skin が有効にならない。

いろいろ試行錯誤して試したところ、 php composer.phar install を実行してからの php composer.phar update で直ったみたい。その後 php composer.phar require mediawiki/chamelein-skin で再び使えるようになった。

composerはよくわからんな。

サーバのアップデート

明日 OS とボイスチャットと掲示板のアップデートをする予定。

CentOS

1. yum -C update を実行する
2. 再起動

Teamspeak3

1. ts3server.sqlitedb にサーバの設定が記録されているので念のため保存しておく
2. teamspeak3-server_linux_amd64-3.0.12.tar.bz2 をダウンロード
3. 古いTS3サーバの sql ディレクトリを削除
4. 新しいTS3サーバのファイルを既存のディレクトリに上書き
5. TS3の起動

phpBB

1. 実行中のバージョンを確認して、対応するアップデートファイルをダウンロードする　(phpBB-3.1.6_to_3.1.7-pl1.tar.bz2)
2. ファイルを展開し、フォルダ "install" と "vendor" を phpBB3ルートディレクトリ（config.php が存在するディレクトリ） にアップロードする 
3. AdminCP の "自動アップデート" を実行する

NetBSD の SSL Root 証明書

NetBSD で Git 使おうとしたらエラーになった。

$ git clone https://github.com/letsencrypt/letsencrypt
Cloning into 'letsencrypt'...
fatal: unable to access 'https://github.com/letsencrypt/letsencrypt/': SSL certificate problem: unable to get local issuer certificate

これは以下の理由によるらしい (引用 NetBSDあるある )。

SSLのRoot証明書がないため。NetBSDはSSLのRoot証明書は、pkgsrcから入れると便利。まず、mozilla-rootcertsをインストールする。

インストール後のメッセージを参考に、

$ sudo /usr/pkg/sbin/mozilla-rootcerts install

を実行したら、なんか大量に /etc/openssl/certs 以下にインストールされた。なお、/etc/openssl/certs が空でないと拒否られる。

StartSSL でやらかした

StartSSL で失敗した話。単に自分の不注意というだけなんだが。

StartSSL は無料でSSL証明書を入手できるサイトとして人気だ。自分もここを利用している。

今回、新たに取得したドメインがあるので、そこも StartSSL の証明書を取得しようとした。

以前取得してから随分日が経っているので、細かい手順はよく覚えてはいなかったが、うろ覚えで操作をした。

まず、ドメインの所有者確認を行って、サーバ証明書の発行手続きだ。CSR を作成するのが面倒だから、プライベートキーは StartSSL 側で生成すればいいか。で、証明書を発行してダウンロードと…。

プライベートキーをコピペして保存しておくのを忘れた。

ブラウザで前のページに戻ろうにも期限切れで表示できず、StartSSL からダウンロードもできないので、プライベートキーは完全に失われてしまったようだ。

新たなプライベートキーを生成して、サーバ証明書を取得しようとしても、発行済の証明書を取り消さないとダメといわれた。当然だ。だが、証明書の取り消しは有料で $24.9 だと。

どうしたものかと思ったが、WoSign Free SSL Certificateが3年無料でマルチドメイン対応かつStartSSLがクロスルートと最強な件 によれば、WoSign という中国系のSSL認証局が無料でSSL証明書くれるらしいので、そこで取ることにした。ありがたい。

証明書を取得するところは英語のページがあるので特に問題はなかったが、アカウント管理には英語版が見当たらなかった。漢字だからなんとなくわかるところもあるけれど、間違えて変なとこクリックしても困るからほっとくか。

.htaccess と RewiteRule

Apache の RewriteRule を設定していて結構はまったのでメモ。

RewriteRule を .htaccess に書く場合、最も深いサブディレクトリにある .htaccess のルールから適用され、その後親ディレクトリの .htaccess のルールが適用される（この動作は RewriteOption で変更可能)。

でも、やってみたら親ディレクトリの .htaccess が全く効いていないっぽい。ていうか、DocumentRoot にのみ .htaccess を置いても無視された。

原因は Alias を使って子ディレクトリを別のディレクトリに向けていたことだった模様。

どいうことかというと、RewriteRule が適用される .htaccess は、URL じゃなくて、実ディレクトリベースで解釈されるので、Alias を使うと親子関係が切れてしまうってこと。シンボリックリンクなら大丈夫。

例えば、

ServerName  www.example.com
DocumentRoot  /var/www/html
Alias  child  /opt/html/child

とかいう場合、http://www.example.com/child/index.html へアクセスすると、実ファイルは /opt/html/child/index.html になる。このとき RewriteRule はプレフィックスを /opt/html/child として解釈し、/opt/html/child の .htaccess にある RewriteRule を index.html に適用する。

URL ベースでみると親ディレクトリに相当する /var/www/html は実ディレクトリベースでは親じゃない。なので、/var/www/html に置いた .htaccess の RewiteRule は参照されない。

これが、Alias じゃなくて下のようなシンボリックリンク貼ってると動作する。

/var/www/html/child -> /opt/html/child

この場合、http://www.example.com/child/index.html へアクセスすると、実ファイルは /var/www/html/child/index.html として解釈される。RewriteRule はプレフィックスを /var/www/html/child と解釈し、/var/www/html/child の .htaccess にある RewriteRule を index.html に適用する。

さらに、/var/www/html は親ディレクトリなので DocumentRoot に置いた .htaccess の RewriteRule も適用される。このときプレフィクスは /var/www/html で 適用対象は child/index.html だ。

まとめると、親ディレクトリの .htaccess で RewriteRule 使いたかったら Alias は使わずシンボリックリンクを使えってことなんだけど、これって常識?