review 5/28 - 6/25

疲労コンパイル気味で書いてなかった <- いいわけ
まとめて。

・Puppet
前エントリの通り、 puppet でごそごそ。

サイトで参考にしたところ
本家 http://www.puppetlabs.com/

ちなみに reductivelabs から名称が変わったのは今年のこと。
http://www.puppetlabs.com/blog/reductive-labs-home-of-puppet-changes-name-to-puppet-labs/

mizzy さんのところ
http://trac.mizzy.org/puppet
記事
http://gihyo.jp/admin/serial/01/puppet

こんな具合にした
- puppetmasterd を動かす passenger 用の ruby (Ruby Enterprise Edition) をインストール
- 前述の通り puppetmasterd は passenger 経由で動かす
- 初回起動だけは webrick. localhost 上で puppetd <-> puppetmasterd の動作を確認したら passenger に切り替えた
- puppetd は --listen --no-client --report 付きで起動、なので puppetrun することで適用
- puppetd 側の設定ファイルは namespaceauth.conf だけ


・3アプリ分本番サーバ用意
「アプリ」と書いているので何のサーバなのかわかるひとにはわかるかな。

puppet でそれなりに仕込みをしておいた後、まず直近の2アプリ分のサーバを構築。
はじめの 1アプリ分で足りてないマニフェストを書きながら構築。
つぎのアプリの分はほぼマニフェストいじらずペシペシ実行して構築。
概ね良好。
アラがちょろちょろと見えてきたので、修正のうえ3つめのアプリのサーバを構築。
3つで計50台弱。まだまだ改良の余地があるな。

こんな感じ
- とある CentOS 5.x な AMI をつかってインスタンス起動
- yum update かけたり、すこしばかり設定した上で AMI 作成する
- 作成した AMI でインスタンスを順次起動
- あとは puppetrun しまくりんぐ (アプリに必要となるブツのインストール＆設定、起動など）

Puppet により、必要なインストール＆設定はカバーしているものの
どこまで AMI に含めておくのが吉なんか、まだつかめてないな。
変に作り込むと、他の者にとってわかりづらくなりそう。
「ふつうの」サーバを構築で OSインストール直後はすべて puppet 、と考えたら AMI はあまりいじらないままでよいとも考えられる。
ただ単に時間を稼ぐなら用途別に AMI 作っておくのはアリ。ポリシーの問題。


・AWS 理解
しばらくお触りする機会が減っていたので、サーバ用意のおかげで覚えなおした。
いまごろ 169.254.169.254 知った。いいねこれ。


・某社や某社のひと来社
サーバつかいませんかといった話が何度か。
ふむ。。


・ルータ
つながらない、つながらないと。「つかえない」「つながらない」「重い」て言うのは誰でもできる。

小規模かつ「べんちゃー」なら、「よーし おらがみてやんよ！」みたいなひといてもいいけど、ここにはいない。
いつのまにやら自分が面倒みてるけど、悪くない。ある意味好き勝手できるからね。


・1年後、2年後
1年後、2年後くらいの方向をぼやーと考えるなど。


・ながっちり
なんだか遅くまで粘ってやってしまうので、早く帰ろう。
遅くまでいる -> 腹減り -> コンビニでちょっとした食料調達、のパターンが無駄。


・知らないひと
事前にマトモなお知らせがないまま人が増えてるのでなかなか気持ち悪い。
気持ち悪いので、知らせてくれと訴えておいた。近いうちに形骸化しそうではある。


・ケムリ
なんだかスモーカーが増えてきたっぽいので今度こそ eneloop でも買ってニオイに対して自衛するか。
ニオイと有害物質がなければタバコは自分でバカバカ吸っているとおもうね。


・社内勉強会
だいぶ自分の領域と違うので、すぐ役立てられる度合いが他の者よりも低いと思う。うーむ。