Mac OS X 10.8 にansibleをインストール
$ wget https://bitbucket.org/pypa/setuptools/downloads/ez_setup.py
$ python ez_setup.py --user
$ sudo eazy_install pip
$ sudo pip install ansible
なんかサーバ構築にやたらと時間かかるんだけど何で時間かかるのか考えてみた
最近サーバ構築を仕事でやっているんだけど、どうにも時間がかかってしょうがない。
色々と面倒な制限があるため、それに合わせるように通常の手順を色々変更しなければならないんだけど、それにしても自分の見積もりより大幅に時間がかかっている。自分の見積もり精度は確かに良くはないんだけどもそれを差っ引いても時間がかかっている気がしてしょうがない。
何故かと考えてみた。
1. 何をやったらいいのか分からない
自分でサーバ構築した経験はあるものの、ほとんど全て自分の開発サーバや勉強用や社内で使うようなものだ。apache入れて終わり、iptablesとか面倒なものは使わない、みたいな場合が多い。なのでいくつかの要件を満たすように複数のミドルウェアの設定に一貫性を持たせた上で構築するということはしたことがなかった。
自分の開発マシン内で使うVMであればcurlを叩けばレスポンスが返ってくるもので普通は十分だけども、外部公開するようなものであれはそうは行かない。httpdサーバとあれどもiptablesなりsshなり場合によってはカーネルパラメータなりと、httpdそれ自体の機能とはほとんど関わりのない部分の設定にも気を遣わなければならない。
が、僕の場合は何に気を使ったらいいのかわからない。それ故時間がかかってしまうのではないかと思った。
例えばセキュリティ面で考えればどこまでやればいいのか?sshは社内のIP以外を弾くようにxinetdの設定をしときゃいいのか?iptablesでやるべきなのか?sshdの設定自体でそういうこともできないのか?そもそもsshdの設定でssh接続できるユーザーをホワイトリスト形式で絞ることはできるけど、それだけで十分じゃないのか?
考えようと思えばきりがないし、どこらへんが落とし所になるのかも分からない。(落とし所を決める権限は作業者の持つものではない気もするが)
だからそこについて考えてる時間が多いのではないかと思った。
(そもそも決定権がないんだからそこをお前レベルの作業者が悩むなよ…ってこともある)
2. 構築フェーズと設定フェーズの分割
普通構築作業が終わったら(運用中にある程度の設定値の変更がありはするだろうけども)その時点でベストと思われるコンフィグの初期設定を行うはずだろう。
僕に降ってきていたタスクは書類上は「構築」という言葉で全てをひっくるめられていたが、実際はそれらの構築フェーズと設定フェーズを伴うものだった。自分自身そこまで構築経験があるわけでもないので、それらが不可分なものであったと思っていたし、その言葉の使い方に違和感を持つこともなかった。世間一般のインフラエンジニア的にはそれらのフェーズはどう認識されてるのか気になるところだけど。
何にしても、僕はそれらの違いについて深く考えていなかったため、構築しては設定して、までをワンストップで行なっていた。だから何か自分の思う通りの挙動をしなくて何が悪かったのかを調べる時に、そもそも構築と設定のどちらが悪かったのか切り分け出来てないためやたらと時間がかかったのではないかと考えた。
が、apacheやnginxであればapachectlとか-tオプションとか付けられるので設定が悪いのか構築が悪いのかは結構簡単に切り分けられるだろうけど、mysqlの場合はそういうオプションがないっぽいのでそれが難しそうだし、設定が悪いと思っていた問題が実は構築フェーズでの問題に引きずられて起こっていたとか容易に想像できるので、これを切り分けが出来たとしてもそれが調査時間の削減に貢献するともあまり思えなかったりする。
結局足りないのは問題の切り分け力?
そもそもボトルネックとなっていた作業はなんだったのかと日報や自分の作業メモを見返してみたけど、目に見えてt明らかなボトルネックが合ったわけではない。ただ、手戻りがちょくちょくあったくらい。
色々考えながら2.を書いてるうちに気づいたんだけど、結局はこの問題切り分け力的なものが足りないから時間かかるんじゃないの?と思った。思えば超当然のことなんだけど。
本当に問題がないのであればミドルウェアのインストールなんてそんなに時間はかからない。適当にググってヒットしたブログにある手順をそっくりそのままコピペすればいいだけだ。
でも現実はそうは行かない。どっかで何かが躓く。結局一番時間がかかっているのはこの躓く何かなんだろう。諸々の設定なりが重なりに重なって不具合を起こしてたり、ブログなどで見た手順と同じ事をしてるけどディストリのバージョンが少し違うために依存性やパスなどの環境が変わっていて動かないとか、単純なミスを見落としてたせいで1日潰したとかよくある話だ。
そういうミスなり不具合がゼロになることはないんだろうけど、それを解決するまでの時間が出来るかぎりゼロに近づけばもっと作業は早くなるんじゃなかろうか。
切り分けと言っても大きくは構築した時に何かが間違ってたのか、設定項目にミスがあるのかというのがあるだろうし、ネットワークまたぎのものであればそもそもサーバが外部に接続できているのか、IPアドレス持っているのかとかいったところから切り分けが出来るだろう。
が、その切り分けをどうやっていくかのポリシーとかチェックリストみたいなのが全くわからないので誰か教えてください。
追記[2013/08/04 1:10]
id:tmatsuu 数をこなす(経験を積む)。Gentooも良い経験になるよ。あとはググって見つかる情報に頼らず、できるだけオフィシャルに近いドキュメントを見るようにしてる。例えばRedHatの公式ドキュメントはよく見てる。
matsuuさんだしやっぱりGentooか!!と思ったけど、一度Gentooみたいにマジで一から設定が必要になるようなものをやってみるのは結構いいのかもしれませんね。
オフィシャルに近いドキュメント見るようにするのは信頼性という意味とある程度体系的にまとまってるからという意味からかな。
数は…頑張ります……
id:houyhnhm ある程度の標準セットとそれからの増減、だろうかな。あと、外部との連携部分がだいたいボトルネックになるのでその辺りを目安にする。
id:spiral 一つのサーバを構築した時自分で記録つけてるのかな? 自ずと何かしら見えてくるんだと思うけれど.毎回白紙からやってたらダメだと思う.あと,誰かの設定の真似をするなら一行一行徹底的に何をやってるか調べるべき
id:gnety ただ構築するだけなら簡単だけど、適切な設定値が何か調べながらやると10倍以上時間かかる
標準セットみたいなのは社内にあったのでそれをちょっと参考にしたりもしましたが、設定をいちいち調べまくってて構築自体が進まなかったのが今回の一番の敗因な気がしてきた…
ただ、標準セットの内容調べても鳥以上に物忘れが激しいので自分用にコメント書きまくったものを用意しておいた方がいいのかもしれない。
nginxでIPアドレス制限
制限をかける
こんな感じでIP制限が書ける。
location / {
deny 192.168.1.1;
allow 192.168.1.0/24;
allow 10.1.1.0/16;
allow 2620:100:e000::8001;
deny all;
}
お決まりのallow,denyで制限したいもの、通したいものを指定。サブネット単位でのアクセス制限も可能。
上の例ではlocationディレクティブの中に入れているけど、http、server、locationどこに書いても大丈夫。
wikiにも「order of the deny/allow is of the utmost importance」とあるようにallowとdenyを書く順番がメチャクチャ重要になる。というのも上に書いているものから評価されるから。
location / {
deny all;
allow 192.168.1.0/24;
}
例えばこんなふうに書いてしまうと、どのアドレスも一番最初のdenyに引っかかってそこで評価が終了してしまって誰も見れなくなってしまう。
リモートの特定ブランチだけ取得したい
一行コマンド記事をqiitaで書こうかブログで書こうかいつも悩む。毎度悩む。悩むたびに、前回書いた時も悩んでいたことを忘れている。結局とりあえずでブログ(orQiita)に書いてしまう。そんで以降どっちにするかを忘れたまま終わる。悩むたびに5本くらい頭髪が抜けている気がする。
git fetch git://example.com/rep.git remote_branch:local_branch
これでリモートのブランチのみを取得可能。masterは手をいれることが無いのでローカルに欲しくない時とかに便利。