requirettyを全力で回避した話
会社で作業をするために使うスクリプトをOCamlで書いてやりました。
で、この過程でrequrettyに苦しめられたのでその辺のメモ。
requiretty外せないサーバ上でsudoしてからコマンド実行しないといけない、呪われた運命を背負った ”>魔法少女 開発者の助けになればな、と。
会社で作業をするために使うスクリプトをOCamlで書いてやりました。
で、この過程でrequrettyに苦しめられたのでその辺のメモ。
requiretty外せないサーバ上でsudoしてからコマンド実行しないといけない、呪われた運命を背負った ”>魔法少女 開発者の助けになればな、と。
清楚かわいいConoHaちゃんは無料トライアルの仕様が超太っ腹だったのですが、今回仕様が変わったみたいです。
簡単にまとめると、
という感じになります。
ConoHaチャージリリース記念のキャンペーンで1500円クーポンばら撒いたのが布石だったとは、誰が想像できただろうか。
nginxリバースプロキシ編に続き、ConoHaのWordPressテンプレートのバックエンド側の設定を読みながら解説していきます。
…とその前に、ConoHa WordPressテンプレートの全体像について確認しておきます。
大雑把にまとめると、Web越しのリクエストを返すために動作するのはnginx, php-fpm, MySQLの3種類のプロセスです。
このうちnginxはキャッシュした結果を返すためのリバースプロキシと、キャッシュがなかったり期限が切れていたりするリクエストを捌くためのバックエンドサーバに分かれています。
またリクエストを返すときに直接は関与しませんが、システム全体が正しく動くよう各プロセスを監視するmonitという監視サーバも動いています。
これらを大雑把にまとめると下図のようになります。
このような感じで、キャッシュが残っているものはリバースプロキシから、キャッシュから返せなかった静的ファイルはバックエンドサーバから、さらにPHPだった場合はアプリケーションサーバーから、それぞれレスポンスが返されます。
なお煩雑になるためレスポンスを書き込みませんでしたが、リクエストの矢印の反対向きにデータが返っていきます。
前回記事で扱ったのがリバースプロキシの部分で、今回扱うのがバックエンドサーバ部分です。
アプリケーションサーバーとかプロセス監視については… 気が向いたらそのうち…
1個前の記事で、「ConoHaってタイトルに入れとけばこのはちゃんが釣れるからちょろい」的なことを書いたら、今回はRTしてもらえませんでした…
まぁそんなことは気にせず、今回もConoHa推しでいくんですけどね。
ConoHaのWordPressテンプレート、VPS立ち上げたら既にnginxやらmysqlやらが全部設定されていて非常に便利なんですが、自分で手を動かさない分ハマったときにちょっと困ったりします。
などなど、自分で構成してないと分かりづらいハマりポイントは多いはず。
ちなみに上記の例は全て自分が踏んだものです。
1個目とか、ハマりポイント以前の問題ですね、すみませんでした…
そんなわけで、自分が読み解いた設定を備忘録兼ねて残しておきたいと思います。
今回はnginxリバースプロキシ編。気が向いたら他のもやるかも、ということで風呂敷を広げておきます。
しばらくは清楚かわいいConoHaちゃんに媚びていく感じの記事でいきたいと思います。
タイトルにConoHaって入れとけばこのはちゃんが釣れるからな… ちょろいもんやで…
というわけでタイトル通り、ConoHaでVPS(WordPress TemplateなのでCentOS)を立ち上げたときに自分が即設定した内容をまとめます。
といっても他のVPSでも大体同じような話ですし、慣れてる人には当たり前のことが多いかもしれません。
一応何度も同じ手順を踏むのは面倒だと思うので、chef soloでの自動化についても触れていきます。
もともとこのブログはレンタルサーバーで動いていたのですが、いい加減VPSに移行したいなー、と思っていたところにちょうどいいサービスが出てきました。
整礎 清楚かわいいConoHaちゃん!
に、WordPressテンプレートというお便利なものができたので、こちらを使ってます。
ついでにデザインも今流行りのレスポンシブっぽい雰囲気のやつにリニューアルしました。
多分スマホとかからでもそれっぽいデザインで見えるはず…?