Webシステム開発の仕事を合理的に実施するためには、まだまだ工夫の余地がある。
例によってまずは要件定義。
- Windowsで動作するお好みのエディタが使いたい。（emacsじゃなくてxyzzyが使いたい）
- お好みのファイラが使いたい。（これはそこまでこだわってない。軽くてディレクトリツリーがまともならOK）
- 環境の切り分けのために自分専用の開発サーバを持ちたいがメモリは食いたくない。
- エディタがセーブしたタイミングで開発サーバにデータを反映させたい。
- チーム開発でも更新差分のデータが損なわれないようバージョン管理をしたい。
- 開発サーバのストレージが許す限り、自動的にリポジトリに登録したい。重要なリビジョンはタグで管理する。
- いざとなったらオフラインで開発出来る仕組みもあると便利。（移動中とかに仕事が進むから）
リモートファイルを更新する方法は結構沢山考えられる。
- scp接続してWinSCPの編集機能で編集する。（たぶん最もベターだがアップロードの手数は必要）
- scp/ftp接続してFileZillaの編集機能で編集する。（編集機能はWinSCPより不便）
- sambaをsshトンネルで使ってWindowsのネットワークドライブとしてマウントする。
- Novell NetDriveを使ってftpをネットワークドライブとしてマウントする。(scp非対応)
- Windowsの標準機能を使ってftp/WebDavをネットワークドライブとしてマウントする。(動作不安定)
- http://webdrive.add-soft.jp/ を使ってscpをネットワークドライブとしてマウントする。(有償 7,875円)
- subversionを経由する。リビジョンの更新に連動してweb領域へのデプロイを行う。(手数は必要)
- ファイルの変更をサーバで検出してsubversionに勝手にcommitする（ユーザはsvnを意識しなくていいが管理は面倒）
ローカルディレクトリの変更をくみ取ってサーバに非同期でアップロードする機能と、
サーバディレクトリの変更をくみ取ってローカルに非同期でダウンロードする機能を持ったscpクライアントがあれば、
要件はすべて満たせる気がしてきた。
ローカルで rsync ssh svn する事が出来れば問題は解決するんじゃなかろうか。
でも、そのためだけにvmwareやcygwin入れるのは本末転倒だし、どうしたものかなあ。
この問題を解決するためにWindows Serverを使えれば良いのだが、これは残念ながら役に立たない。
考えられるとすれば、RDC 7.0でサーバ上の仮想ゲストWindowsにログインして、サーバで全作業をする事だが、
エディタの入力中にネットワーク遅延が発生して表示が遅れたりしたら発狂しそうだ。
思うにWindowsのツールってTCP/IPとの相性が悪い気がする。
このソフト入れてこのポート開放すればうまく使えまっせ、というだけの仕組みが少なくて複雑怪奇である事が多い。
WebDavとかはRDCみたいなリッチな仕組みは好きなのにね。
2010-01-17 09:36:26
Linux
Comments: 0
モダンでカジュアルなメモリ管理を考える。
- swapパーティションは必要ない。（物理メモリは安価で潤沢なので、swapの常時発生を前提としたシステム構成は行わない）
- しかし、不測の事態が発生して物理メモリが無くなったら、システムやプロセスを停止するのではなく、swapを発生させて一時しのぎをしたい。
- 物理メモリに余裕がある時点では swap out して欲しくないし、swapファイルも作成して欲しくない。（可能であればメモリに余裕が出来た時点で自動的に削除して欲しいくらいだ）
要件を書いてみたら、最後以外はもろに Windows 95 の win386.swp と同じだった。
ちなみにMacOSXのmachカーネルも要件を満たす実装を行っているらしい。
Linuxはメモリ管理がすごく杜撰で、サーバ管理者の頭を悩ませているようだ。
- プロセスは、物理メモリと仮想メモリの容量を超えてメモリを割り当てる事が出来る。(mallocに成功する)
- 割り当てたけど使っていないメモリを、他の用途に割り振ることで、実際よりも多くメモリが使えるよう見せかける。
- この仕組みのせいで、存在しないメモリをバッファに使おうとするソフトウェアが実在するらしい。なんてこった！
- 割り当てたメモリが本当に使われてしまうと破綻するが、このときOOM killerというカーネルの機能が発動し、プロセスを殺す（！）
- OOM killer対策方法はいくつかあるが本質的ではない。
- そもそも、あるぶんしかメモリ割り当てをさせない。
- 私は殺さないでくれ（他の奴を殺してくれ）と、あらかじめ指示しておく。
- OOM killerそのものを殺す。無いメモリを使おうとしたらカーネルパニックで全員死ぬ。
- 後に /dev/mem_notify という機能が追加されたらしい。
- プロセスはあらかじめ /dev/mem_notify を poll する実装をしておく。
- メモリが少なくなってきたら /dev/mem_notify は「割当量を減らしてね」と表明する。
- プロセスは、その表明に応じてメモリの割当量を減らす。
OOM killerが動的にswaponしてくれれば誰も死ななくて済むのに、なんで誰もそういう発想に至らないんだろう。
プロセスを殺す暇があったらメモリ確保も出来るんじゃないかと思うけど、ddに時間がかかるからだめなのかねえ。
現実的な実装は mem_notify の通知を受けてswapの容量を増やすデーモンを常駐させておけばいいのかなあ。
512MBなり1GBなりの単位で新しいswapファイルを作ればいいんだな。めっきりMacと同じ実装に見えてきた。
しかし、Webで得られる情報を見ると、
mem_notifyはシステム全体の空きメモリが足りなくなり、スワップが始まりそうになったタイミングで、メモリを開放するようにアプリケーションに通知するというフレームワークです。
と書かれており、微妙にOOM killerと噛み合ってないように見える。
「スワップが始まりそうになったタイミング」で本当にスワップが始まってくれるなら、なんも困らないのだけどなあ。
前提
- コンサバで64bitなLinuxを導入したいのでCentOS 5.4 x86_64版をインストールした。
- OSインストール時には古いphpとmysqlはインストールしなかった。
- 新しいphpとmysqlをインストールするためにremiリポジトリを使う覚悟を決めた。
- remiリポジトリではphp 5.3を入れると、mysqlを5.1に上げないといけないが、それも了承した。
- ただし、remiはyumの自動アップデートの対象には含めないことにする。
リポジトリの追加
yum -y install wget
wget http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noarch.rpm
wget http://rpms.famillecollet.com/el5.x86_64/remi-release-5-6.el5.remi.noarch.rpm
rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm
vi /etc/yum.repos.d/remi.repo
[remi]
priority=1
vi /etc/yum.repos.d/epel.repo
[epel]
priority=1
enabled=0
phpとmysqlのインストール
yum remove php* mysql*
yum install --enablerepo=remi,epel mysql.x86_64 mysql-devel.x86_64 mysql-server mysql-test
yum install --enablerepo=remi,epel php php-mbstring php-mysql php-pdo
php -v
mysql -V
service mysqld start
service httpd start
mysqlのインストールに失敗する場合は
remiのmysqldは初期状態が微妙に変だ。
mysqlデータベースのuserテーブルにレコードが無いとか、色々おかしい。
killall mysqld
/usr/libexec/mysqld --skip-grant-tables &
mysql_update
mysql mysql
INSERT INTO user VALUES('localhost','root',PASSWORD('パスワード'), 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y', 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y', '', '', '', '', 0, 0, 0, 0);
quit
killall mysqld
service mysqld start
うちの場合は、これでうまくいった。
GRANT命令が使えない環境下でuserテーブルをいじる方法を覚えてないと、メンテが出来なくなるね。
localhost以外からrootで接続できるようにするには、以下のクエリも実行すれば良いが、WebサーバとDBサーバを分ける等の運用をするわけではない限り必要ないと思う。セキュリティリスクを伴う。
INSERT INTO user VALUES('%','root',PASSWORD('パスワード'), 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y', 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y', '', '', '', '', 0, 0, 0, 0);
2010-01-12 04:37:33
Linux PHP
Comments: 0
熱心なPHPerとしては、やはりPHP 5.3が使いたい。
5.2までのソースコードを使うとしても、PHPのバージョンは5.3にしておきたいのだ。
5.2から5.3で微妙に変わった仕様もあるので対応が若干面倒にはなるが、
fedora 11に入っているPHPのバージョンは5.2.1らしく、これではsymfonyが動かない。
また、将来的にPHPの主要なフレームワークはどれもPHP 5.3以上を条件とするため、そぐわない。
fedora 12であれば、PHP 5.3.0が入っている上、5.3.2用のrpmもあるので将来は安泰である。
しかし、何年たってもリリースが見えてこないRHEL6は、fedora 11をベースにするという噂が流れたっきりだ。
Microsoftといい、隆盛をきわめたOSメーカーがここ数年アップデートを出せてこなかった事が、
IT業界のソフトウェア的インフラの発達を止めてしまったんでないかとか、PHP4erが減らない原因なんでないかと思う。
（Windows Web Server 2008 R2でもPHP 5.2.11しかサポートされていないな、そういえば）
CentOSにepelを導入してもこの問題は解決されないので、大抵はremiというリポジトリを使っているようだ。
結果的にremiはユーザの多さという点で一定の信頼性を獲得しているとも考えられるが、どうも不安が残る。
remiでyumしたphpと、自分でビルドしたphpのどっちが顧客のメガネにかなうかは微妙なところだ。
サーバOSが枯れている事は大事だが、数年前のOSに足を引っ張られていては時代に取り残されてしまうのも事実。
ビジネスやサービスやスキルアップなどの目的を踏まえつつ、次のいずれかの方針から選択していきたい。
- 仮想化テクノロジーを活かして、最新版のfedoraをサーバにして、常にマイグレーションを怠らない
- コンサバな事は大事だからCentOSにremiを入れて頑張る
- いっそRedHat系のOSはあてにならんと判断して他のディストリビューションやOSにしちゃう
理想論で言うと、たぶん全部並行してやらないといけない事なのだろう。
でも、この3つの中で1つだけ選ぶとしたら、それは最もコンサバな選択肢になるはずだ。
だって、そもそもRedHat系のOSを選んでいる事自体がコンサバを求めた結果なのだから。
ディストリビューションに対するブランド力は落ちるが、パッケージ構成が信頼出来れば他の選択肢もありうるので調べた。
Plamo Linux 4.7は、PHP 5.2.11なのが惜しまれるが方針としては共感出来る。
mysqlが入っておらず、postgresqlを使わされる所も割と好印象だ。悪く言うと融通がきかなさそう。
Ubuntu 9.10はPHP 5.2.10で、Slackwareは謎。FreeBSDのportsにあるPHPは5.2.12。
とりあえずパッケージ一覧がWebで容易に参照できないディストリは滅べばいいと思う。
本当の目標は、
Hyper-Vサーバ --- (インターネット) --- 管理PC
という環境で管理出来るようにすることなのだけど、その前段として、表題の構成を実現する。
Hyper-Vサーバ --- 管理PC --- (インターネット) --- 任意のPC
とりあえずこれが出来れば、LANの外から管理する事が可能になるはずだ。
最も簡単で合理的な方法は、おそらく hamachi のような VPN を使う手だと思われる。
しかし hamachi のセキュリティが信頼できるかが不透明なので、本番で使うのが怖い。
よって、かわりに ssh トンネルを使うことにした。
しかし、残念ながら Windows には公式のフリーな sshd 実装が無い。
自社のプロダクトのセキュリティに気を遣うと言うのであれば実装は必須だと思うのだが。
仕方ないので Linux 環境を別途用意する。
仮想環境で用意してもいいが、それだと自分自身(Hyper-Vや仮想Linux)の再起動が危険になる。
Hyper-Vサーバ --- 管理PC --- Linux(sshd) --- (インターネット) --- 任意のPC
なんかもう超だるい構成になってきた。肝心の手順は以下の通り。
- 管理PCにHyper-Vマネージャを入れて動作可能な状態にしておく。
- 管理PCのIPアドレスを固定する。
- Linuxにsshdを立てて、インターネット経由でログイン出来る安全なパスワードのアカウントを作成する。
- ルータをLinuxに対してsshdのポートをフォワードするように設定する（ポート番号は変えると良い）
- 管理PCのログインパスワードが安全であることを確認する。
- 管理PCでリモートデスクトップの接続を受け付けるよう設定する。
- 任意のPCが Windows 7 未満の場合は、接続の設定を「低」にする必要がある。
- 任意のPCに putty を入れる。
- 「接続」「SSH」「トンネル」メニューを開き、源ポートに任意の番号(1024-65535)を、送り先に管理PCのIPアドレス:3389を入れて「追加」
- 任意のPCでリモートデスクトップ接続を開き、localhost:源ポートに指定した番号 に接続する。
最初からLAN内にsshdのある人にとっては超余裕。
そうじゃなくても、ルータのポート3389を開放するよりは安全と言える。
Linuxは用意できないけど、cygwinとWindows版のOpenSSHバイナリをインストールしてもいいという方はこちら。
http://cygwin.com/
http://sshwindows.sourceforge.net/download/
これを管理PCにインストールすれば、3台目のサーバを設置する必要は無くなる。
また、これを応用して、ゲストOSのリモートデスクトップにも直接接続出来る。
ちなみに「本当の目標」については、失敗事例がたくさん見つかる。
Hyper-Vマネージャは、接続設定にIPアドレスやポートを指定することが出来ないらしい。
localhost の netbios や epmap は自分の Windows のために使われているはずなので、
ポート番号を変えずにトンネルする事は出来ない。
なので localhost に接続しようとすると Hyper-V につながる、というようなトンネル設定には出来ないと思う。
やはりhamachiにしようかとも考えたが、Hyper-Vにインストール出来ないので厳しいと思う。
ゲストOSに入れて、本来のサブネットにブリッジさせれば動くかも知れないが・・・。
願わくば、Hyper-Vサーバ上にHyper-Vマネージャがあって、
それがセキュアなリモートデスクトップ接続で制御できるならそれが一番だと思うのだが、
そういう管理が出来ないのは、Windows Server 2008 R2との差別化なのだろうか。
管理PCを買ってくれ、Windows 7 Professionalを使ってくれというのはいいとしても、
せめてリモートで操作可能なポート構成にはして貰えないものだろうか。
これなら、Webアプリで制御出来たほうがまだマシだと思う。管理用のhttpsポートを開放するだけで済むのだし。
将来的には、めざせKVMスイッチということで・・・。
