S3とNginxを組み合わせてキャッシュさせる……

改名関係の記事は裁判所に面談に行ってからの進展の時点で書きますね。

ということで、今回はS3ネタです。

わたしの所のサイト群の中でTwitterのプロフィールメンテナンス情報ページがS3を使用するという形で公開されています。

このブログと同じサイトでサイトを公開することももちろん出来ます(その方が追加費用もかからないし)が、サーバー停止時にS3ホスティングしておけばサーバー停止時にもページを公開し続けることが可能です。
(メンテ情報は何が起こっているのかを公開しなきゃいけないしTwitterからプロフィール見たい人が見れないのは困るでしょ?)

といっても転送量がかかるわけですねf^_^;)

料金 – Amazon S3 | AWS

こんな感じでね。

このブログも何気なく常時SSL化していますが、最近はSSL化するのが一般的になりつつあるので、SSL化もしたいですね!!

S3を独自ドメインでSSL化するためには、CloudfontをSSLアクセラレーターとして使うことで実現できます。
(こっちの記事を書かなきゃなんだよねf^_^;))

S3→Cloudfront間は転送量がかからないしても、Cloudfontの転送量はどちらにしてもかかりますね(-_-;)

料金 – Amazon CloudFront | AWS

まあ、実際のところはわたしのS3ホスティング委託分のサイトは数KBなのでそんなに気にする程ではないですけどねw

といっても「ちりも積もれば…(ry」ということなので解決しちゃいます!!

このブログで使ってるサーバー(VPS)にキャッシュさせてしまえ!!(そうすればSSLアクセラレーションもできるし)

ということです。

(゜_゜;)…って最初の方に「S3ホスティングしておけばサーバー停止時にもページを公開し続けることが可能」とか言ってなかった?
これじゃVPSが単一障害になるよね?
ってなりますね。

こまけぇこたぁいいんだよ!!

というのは冗談ですが、もちろん対策はしています
が……

とりあえず、解説しちゃいますね。

S3は外部から参照可能な状態にしておいてください。
方法はこちら……
Amazon Web Service S3でWebページをホスティングする……

ということで、外部アクセス可能な状態ならOKなのでNginx側を設定します。

今回は、「/var/www/cache/」の配下に「site-a」というフォルダをさらに作成しそこにキャッシュしてもらうという形にします。

当サーバーではnginx.confに「include /usr/local/nginx/etc/conf.d/*.conf」と設定してサブドメイン毎に設定ファイルを分けていたりしますが、まずは「http」ディレクティブを編集するので、nginx.confを編集します。

nginx.conf

proxy_cache_path /var/www/cache/site-a levels=1 keys_zone=site-a:2m max_size=10m inactive=10080m;

httpディレクティブ内のどこかにこの様に記載します。

/var/www/cache/site-a
どこに場所にキャッシュを保存するかを設定しています。

levels=1
どのぐらいの階層の深さでキャッシュを保管するかという設定値ですが、今回はキャッシュ毎に場所を指定するので直下に展開させます。

keys_zone=site-a:2m max_size=10m inactive=10080m
keys_zone=site-a:2m ですが、site-aという定義を指定しています(これは後に使う)、そして2mの部分はキャッシュされるファイル1つにつき128バイト使うそうなので、キャッシュするファイル数に応じて設定します。(S3で公開しているサイトは4つぐらいしかファイルがないのでもっと少なくても大丈夫だけど余裕持たせています)(1mでもいいかも……)
max_size=10mはキャッシュの大きさです、つまり10MBを超えるとキャッシュが古い方から削除されます。(これも絶対そんなに使わない)
inactive=10080mは有効期限です、期限内はキャッシュからサイトが表示されます。
今回は10080分=7日間で設定してあります。

「proxy_cache_path 」を増やしていくことによって、フォルダ毎にキャッシュ出来るようになります。
そのときに、「keys_zone=」の部分は違う物を指定してくださいね。

ちなみに……
実を言うと、キャッシュ毎にフォルダを作る例はあんまりないんですが、今回はキャッシュ削除を簡単にできるようにするために設定してあります。

こうしておけば……

# rm -rf /var/www/cache/site-a/*

として簡単にキャッシュが削除できますf^_^;)

次にバーチャルホストで公開する、リバースプロキシーの設定用ファイルを作成します。

今回はこんな感じで作ります。

site-a.example.com.conf

server {
  listen 80;
  server_name site-a.example.com;
  location / {
  return 301 https://site-a.example.com$request_uri;
  }
}
  
server {
  listen       443 http2;
  server_name  site-a.example.com;

  ssl                  on;
  ssl_certificate      /etc/pki/tls/certs/ssl.crt;
  ssl_certificate_key  /etc/pki/tls/private/secret.key;

  ssl_protocols        TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers          CHACHA20:AESGCM:HIGH:!DH:!aNULL:!ADH:!MD5;
  ssl_prefer_server_ciphers   on;

  ssl_session_cache    shared:SSL:10m;
  ssl_session_timeout  10m;

  location / {
     resolver 127.0.0.1 valid=5s;
     proxy_pass S3のWebホスティングのアドレス;
     proxy_cache site-a;
     proxy_cache_valid 200 10080m;
     proxy_intercept_errors on;
     }
}

今回は、httpでアクセスしてきたら問答無用で301をするように設定してあります。

SSL関係の設定値はNginxで直接サイトを公開する場合と変わりませんので、locationディレクティブの設定値について詳しく書いていきます。

resolver 127.0.0.1 valid=5s
Nginxは仕様上、起動時にリバースプロキシー先のIPアドレスを解決してそれ以降はIPアドレスでアクセスしようとします、それだとS3を使う場合不都合なので前回の検索から5秒を超えていたら再度IPアドレスを解決するように設定します。
(ここでは127.0.0.1となっていますが、名前解決できるDNSキャッシュサーバーを指定してください)
Route 53のエイリアスレコードのTTLって……
(S3のTTLについてはここに少し書いてあります)

「proxy_pass S3のWebホスティングのアドレス;」
ここにはS3のWebホスティング先のURLを指定します。
リージョン毎に違いますので、「proxy_pass http://なんとか.s3-website-us-east-1.amazonaws.com/;」みたいになると思います。

「proxy_cache site-a;」
「keys_zone=site-a:2m」で設定してあったkeys_zoneの名前を入力します。
これで、先ほどの位置にキャッシュされていくようになります。

proxy_cache_valid 200 10080m;」
ここでは、どのレスポンスコードに対してどのぐらいキャッシュするのかを指定しています。
今回は、200 OKだった場合は7日間キャッシュするようにしています。
ちなみに、「proxy_cache_valid 404 60m;」とすれば404エラーを1分間キャッシュという形になります。

proxy_intercept_errors on;」
Nginx内でカスタムエラーページを使用している場合に設定します。
この設定を入れておくと404エラーなどでカスタムエラーページを使用しているときにNginxで使用しているエラーページになります。

# mkdir /var/www/cache/site-a
# chown nginx:nginx /var/www/cache/site-a

Nginxを起動する前にこんな感じで、フォルダを作っておいてくださいね。

あとは、DNSの設定をしてNginxをリロードまたは再起動してサイトが表示されれば完了です!!

気になる冗長化については、Route 53のフェイルオーバーをほんとの意味で正しい使い方で使っています。

これで、Nginxでキャッシュしているサーバーが停止していてもCloudfront経由でサイトの公開は継続することができるわけですね(^_^)v
(使った分だけのAWSのいいとこ取りですね(>_<。))
(この辺も解説しなきゃだめ?ですよね……)

 


改名手続き(その1)……

裁判所|名の変更許可

ということで、前もいろいろこのブログに書いていくって言ったので今回はGID(性同一性障害)のことについて書いていきますね!!

これからの標準? CDNとは…?

この辺の記事で診断書をもらったとかちょっと触れていますが、わたしはGIDということであるメンタルクリニックの先生から診断書をいただいています。
まあ、この辺の詳しい事は書く機会があれば書いてもいいけど今日はこの辺で。

ということで、見た目がいろいろと変化すると名前がすごく問題になるわけです。
(最近だと奥さんということで通しちゃう時もあります(-_-;))

というのもあって改名手続きに入っていこうかなって思います。

ということでいろいろ調べると……

・改名は申立人(←自分ね)の住所地の家庭裁判所でする必要がある。
つまり、わたしの場合は川口市なのでさいたま家庭裁判所(さいたま市浦和区)に申し立てする必要があります。

・必要な物は、収入印紙800円分(←ここはどの地域も共通みたいです)と連絡用の郵便切手(←ここは地域で違うらしい)
収入印紙は800円分用意してください。(ちなみに400円が2枚になるらしいですよ←郵便局のお姉様に800円はないと言われました(-_-;))
連絡用の切手については、地域で違うらしいです。
ちなみにさいたま家庭裁判所に電話したら82円切手が3枚ということでした。(←郵便局で間違って83円と言ったのは秘密w)
切手は17枚と言われている地域もあるらしいので必ず電話で確認してください。(←埼玉でも念のため自分で確認してくださいね)

・申立人の戸籍謄本
これに関しては本籍地の区役所などで取る必要があります。
わたしの場合は江戸川区になるので……

450円ですね。
申し立てのために裁判所と改名が通った場合は市役所(川口)に提出する必要があるようなので、とりあえず2枚取っておくつもりです。
ここに関しては遠方の方は郵送なども可能だと思います。(江戸川区はOK)
わたしは、来週に実家にネットワーク機器の定期点検ということにしてますが、親にものすごくいろいろ心配されているので、会いに行くついでに取りに行ってきます。

・診断書とか名前を使っている証明となる書類
今回はGIDが事由とするのでGIDの診断書と実績はヨ○バシ.comとかAmaz○nの納品書とかで大丈夫らしいです。
ちなみに、GIDが事由なら実績はいらないという説もあります。(東京はそうらしい?)
ちなみに実績は半年でチャレンジします。(←埼玉はいけるらしい?)

・申立書
PDFがあるのでそれを書く感じですね。
わたしはまだ書いてないですけどね(-_-;)
(手書きが超超苦手です。←女の子らしくかかないとまずいし……)

わたしは、郵送じゃなくてあえて直接裁判所に出向くつもりです。

いわゆる連続系企画ですが、どうなるかわからないので次回更新は未定にしておきますね。(そのいくつになるのかなw)

郵便局で買いました!!

次回の改名までの記事は戸籍謄本のあたりで更新できたらなって思います(^_^)v


nginxをBoringSSLで使う……

みなさーんOpenSSLで苦しんでますかー?

わたしは苦しんでます(-_-;)
昨日のメンテはOpenSSLの絡みだし。

OpenSSL 1.1.0eがリリース……

この記事でも書いていますが、OpenSSL(特に1.1.0系)はぜい弱性が多いわけです。

なので、フォーク(OpenSSLをベースとした別の物)を使いたいと思います!!

boringssl – Git at Google

最近はLibreSSLなども派生種としてありますが、今回はGoogleがフォークしたSSLであるBoringSSLを使います!!

参考にしたサイト……
为论坛使用 BoringSSL (Nginx + BoringSSL)的流程记录 | Set☆Fire (・へ・) Community 集火社区

はい……
日本語ではありません(゜_゜;)
(作者のアイコンはFateっぽいけどね)

まあ、いいでしょう。

必要な物……(今回はCentOS 7を使用します)
・Nginxがビルド出来る環境。
(ここは今までビルドしたことのある環境として説明しません)
・git
・cmake
・golang

Nginxが既にビルドしたことある環境なら追加は3つぐらいです。

ということで、必要な物をサクッとインストールします。

# yum install git cmake golang

とすれば勝手に入ってくれるはずです。

ということで、Nginxのソースは事前にダウンロードしてください。

今回は、「/usr/src」で作業する想定で、Nginxはバージョン1.11.10を使います。

# cd /usr/src
# git clone https://boringssl.googlesource.com/boringssl

という形でまずはgitでBoringSSLを落としておきます。

# tar xvzf  nginx-1.11.10.tar.gz
# cp -r boringssl nginx-1.11.10/boringssl

Nginxを解凍して、BoringSSLを事前にコピーしておきます。

# cd nginx-1.11.10/boringssl

として、Nginxのフォルダ内にコピーしてBoringSSLの階層に移動します。

# mkdir build
# cd build.
# cmake ..

buildフォルダを作成し、階層を移動してcmakeを実行します。
cmakeが完了するはずです。

# make
# cd ..

makeをして完了したら、階層を1つ上に上がります。(boringsslの階層になるはず)

# mkdir -p .openssl/lib
# cd .openssl

.opensslと同時にlibをその階層の下に作成します。

# cd .openssl
# ln -s ../include

階層に下りて、includeにシンボリックリンクを貼ります。

# cd ..
# cp build/crypto/libcrypto.a .openssl/lib
# cp build/ssl/libssl.a .openssl/lib

1度上の階層に戻りlibにファイルをコピーします。 

# cd ..

そして、Nginxの階層に戻ります。
あとは、Nginxをコンパイルします。

# ./configure --prefix=/usr/local/nginx --conf-path=/usr/ local/nginx/etc/nginx.conf --with-http_ssl_module --with-http_v2_module --with-openssl=./boringssl

ここのconfigureオプションについては、環境に合わせて設定してくださいね。
「–with-openssl=./boringssl」の部分はOpenSSLの代わりにBoringSSLを指定します。

あとは…makeしてmake installとか思ってます?

そうなんです、そんなに簡単じゃないんです(-_-;)

make[1]: *** [/usr/src/nginx-1.11.10/boringssl/.openssl/include/openssl/ssl.h] Error 127

というエラーが出て止まります。

さてと……
どうしようかな……これ書いてないんだよね(-_-;)

ということで、ググってみると……

Kimiya Kitaniのブログ纏めサイト: 【備忘録】 nginx + LibreSSLのソースからのコンパイルに挑戦

LibreSSLを使用しているパターンの方ですが、同じようなエラーに遭遇したみたいです。

おそらく、NginxがOpenSSLとしてコンパイルしようとするのを阻止しないといけないのでそれを止める必要があるらしいです。

それを止めるために、ssl.hの日付をconfigureより後にすればいいらしいので……

touch boringssl/.openssl/include/openssl/ssl.h

として更新日時を変更します。(そのソースで実行していてもモジュール追加とかでconfigureをしたら必ずこのコマンドを実行)

これであとは……

# make
# paco -D make install ←pacoを使っている場合

わたしはpacoを使うのでこんな感じですが、make→make installをすれば完了なはずです!!

# nginx -V
nginx version: nginx/1.11.10
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) 
built with OpenSSL 1.0.2 (compatible; BoringSSL) (running with BoringSSL)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --conf-path=/usr/local/nginx/etc/nginx.conf --with-http_ssl_module --with-http_v2_module --with-openssl=./boringssl

 「(compatible; BoringSSL) (running with BoringSSL)」と表示が出ていれば問題無く完了です!!

これで安心してBoringSSLで使えそうですね!!