Windows環境メインのLAMP開発について

質問

お世話になります。
正直、開発関連のカテゴリに投稿しようか迷いましたが、Linuxの機能に
大きく依存する部分がありますのでこちらで質問させていただきます。
結果的に連投になってしまっていますが、ご容赦ください。

さて本題ですが、表題の通り、
Windows環境メインにおけるLAMP開発をしています。

◆まず、現在下記のような状態となっています。

○メイン開発機
　・デスクトップPC、OSはWindows8 Pro(x64)
　・開発サーバとして、Hyper-V上にCentOS6.3を導入

○サブ開発機
　・ネットブック、OSはWindows8 Pro(x64)
　・仮想化非対応な上、VMWareとか乗っけるとメモリ容量的に死ねるので、
　　Fedora18がリリース次第デュアルブート環境構築してやむ得ずLinux上で
　　開発しようかなと考えています。主に外出時(地下鉄乗っているときとか)
　　に短時間しか使わないのが幸いでしょうか。

○テストサーバ 兼 SVNリポジトリやRedmineなどのプロジェクト管理サーバ
　・CentOS6.3 VPS(KVM)です。
　・基本的にはステージングサーバとして運用しますが、Webアプリの種類に
　　よっては、これがいきなり本番サーバとなることもあります。

○本番サーバ
　・CentOS5.5 ただのレンタルサーバです。

◆とりあえずやりたいこと
1.Windows上でコードを書く。(できる限り開発はWindows上で行いたい)
2.コードを保存した瞬間、開発サーバにデプロイされている。
3.パーミッションの設定など、最低限のことだけサーバ上で行う。
　(これについても基本的にはSVNの実行権限プロパティなどを用いるようにする)
4.http://開発サーバのIPアドレス/でコーディング結果が表示される。
5.Windows上で、または開発サーバ上でSVNリポジトリへコミットができる。
6.コミットしたらテストサーバにもデプロイされる。
　(まぁこれはpost-commitに細工仕掛ければどうにかなりそうな気がする)

◆できていること
1.テストサーバでSVNリポジトリを更新する。(ただし手動)
2.1の段階で即デプロイに等しい状況になっていて、
　http://テストサーバ/で結果が表示される。
3.本番サーバで特定コマンドを手動で打つとSVNの内容をエクスポート、
　全自動で上書きデプロイまで行う。

◆困っていること
長々と現在の環境について説明してしまいましたが、現在困っているのは
「とりあえずやりたいこと」の1～3に該当する部分です。つまり、
WindowsとLinuxで同じ(物理または仮想)ディスクを使うことになるのですが、
これがなかなかうまくいきません。

◆考えてみたソリューション

・FTP、後にSFTP転送によるデプロイ
　13年前～10年前くらいまで使っていた手法ですが、そもそもデプロイを
　省略して、ソースを保存後即デプロイという状況を作りたいため却下。
　また確実に上書きしないとソースの整合性が取れなくなるのも難点。

・Windows上にLAMP風環境を構築、Windows機をそのまま開発サーバ化
　9年前～4年前くらいまで使っていた手法です。ただ、Windows上だと
　動くけどLinux上だとなぜか動かない！というケースがあるので、
　かなり頻繁にステージングへデプロイしたり、Windows上にない機能に
　依存しているライブラリを避けるために面倒なことをしたりと大変でした。

・Windowsでコーディング、コミット後テストサーバで更新かけて確認
　3年前から今に至るまで主に使っている手法です。確実にソースの整合性が
　取れますがデプロイの省略とならないこと、またコミットログが
　猛烈に肥大化するためできるだけこの方法は今後避けたいです。

・Cygwin、またはInterix(SFU/SUA)
　Cygwinは最初から期待していなかったですが、メイン開発機をVistaに
　アップグレードして以来SUAは一時期本気で開発サーバ構築できないかと
　期待して弄り倒したことがあります。何かと仕組みが独特で構築は非常に
　困難を極めましたが、それなりのものが出来た感じです。ただ、
　Windows上にLAMP風環境を構築するよりは遥かにマシなものの、やはり
　ステージングで動かない！があったり、またWindows8はSUAが非推奨、
　今後はサポートされないと話を聞き、今後のことを考えると
　この方法は断念せざるを得ないのかな、と思うところがあります。

・ホストPCのパーティションを区切って、NTFSでフォーマット、
　ゲストからルータ経由でマウントする方法
　編集即反映されるので一見よさそうに思えましたが、Linux側から
　一般ユーザ権限で書き込みできないのと、パーミッションが
　固定されてしまうのがちょっと痛くて断念しました。

・VHDXファイルをホストからマウントする方法
　ext4ファイルシステムをWindows上でマウントするのには一癖有るというのは
　予備知識として知っていましたが、そもそもそれ以前にホストかゲストかで
　排他的にしかマウントできないことが発覚して、即撃沈。

・WebDAVを使う
　パーティションの共有を諦めてWebDAVで読み書きしてしまおうというやり方。
　一見これもアリかなと思ったのですが、Windows上からコミットできないのと
　ソースではなく「実行結果」が帰ってくることがあるのでこれも撃沈。

・Hyper-Vによる開発サーバ諦めて、Linux PCを家庭内LANへ導入する。
　正直出費は避けたいので……。ただ、1台だけPCが余っているのですが、
　「2002年末頃の超ハイエンドPC」で、スペック的には今時でもギリギリ
　通じるレベルではあるのですが、消費電力と駆動音を考えると……orz

・Sambaサーバを使う
　もし本当に何もかもお手上げなら、これが最後の駆け込み寺か……。

◆さいごに
レンタルサーバを使ったWebプログラミング自体は12年前から始めて
いましたが、業務歴およびVPSや専鯖によるLAMPサーバ構築歴はかなり浅く、
Linuxの知識も正直言うほど豊富とは言えません。

もしこれ以外にもこういうソリューションがあるよ！
とかあれば、ご教示戴けると幸いです。
以上、長文でお手数おかけいたしますが、よろしくお願いします。

回答No.1

春原 なの（@ymda） · ベストアンサー

こんにちわ。

＞デスクトップPC、OSはWindows8 Pro(x64)
＞開発サーバとして、Hyper-V上にCentOS6.3を導入
開発サーバーというかWin8配下のHyper-Vですよね？

＞ネットブック、OSはWindows8 Pro(x64)
＞仮想化非対応な上、VMWareとか乗っけるとメモリ容量的に死ねるので、
おそらく動かないですが、運よく動いたとして、Win7のXPモードと
同等のVirtualPCですと、仮想化非対応でも公式パッチで激遅ながら
動くようです。

＞CentOS6.3 VPS(KVM)です。
距離が離れるマシンに対して、直接ファイルアクセスするのは
快適でないので、やめておいたほうがよさそうです。

それはそうと・・・

今、デプロイをしているうちの環境が、比較的原始的で
cvsを利用しています。
＃いいかえれば、cvsに依存しすぎて、他に移動しきれないのもあるのですが・・
今や多くのLinuxあたりのクライアントでは、cvsは標準、または
容易に入手可能ですので、やってみても良いかなというところです。

また、
＞Windows上にLAMP風環境を構築、
WAMP環境？ですか
これはやめておいたほうが無難かもしれませんね。

＞Windowsでコーディング、コミット後テストサーバで更新かけて確認
・・・
＞猛烈に肥大化するためできるだけこの方法は今後避けたいです
実は、うちが考えている一つとして、dropboxとバッチシェルを使って
デプロイできないかということです。
dropboxは、このような種類で唯一多くのプラットフォームに対応しており、
Linuxでも対応しています。
詳しい部分はまだわからないのですが、一台別の仮想（開発）サーバーを
作って、試してみても悪くない話です。
dropboxに投げ終わったら、httpで(MD5やSHAの）チェックサムを送り、受けた側は
チェックサムの整合性がとれたら、デプロイを直接サーバー側で
行なう感じです。

結局は・・Windows上で「楽」を考えると、
Linuxの実機の下にある仮想（もしくは、Hyper-V OSの下の仮想）に
telnet（ローカルな為可）やsshでアクセスをしたうえで、更に
sambaでWindowsにドライブ名を割り当ててしまったほうが
気楽なのかもしれません。

お礼

早速のご返答ありがとうございます。
色々と参考にさせていただきます。

もうストレージ丸ごと共有するのを大人しく諦めて、Hyper-V上の仮想サーバに
Samba構築するか、NFS構築してホストを参加させるか……と考えていたのですが、
おかげで一つ閃きました。SVNの作業コピーをDropbox上に設置することです。

これなら確かに完全自動でデプロイできるはずです。ただ、難を挙げると
一旦Dropboxを経由するので数秒～数十秒ラグがあることですね……。
(もう一つ強いて難を挙げるとCentOSのsvnクライアントのバージョンが
古いですが、まぁそれはどうにでもなるでしょう)

あと一つ考えたのが、ホスト側PCでLive CD版Linuxを立ち上げて、HDDの
空き領域にNTFSではなくext3(できればext4)のパーティションをこさえて、
それをゲスト・ホスト双方でマウントする方法。
これならVHDXみたいな排他で引っ掛かることもなさそうです。
(Windowsからのext4マウントは一癖ありそうですが、
やってみる価値はありそうですね)

もし他にもこんな解法があるよ！とかありましたらご教示戴けると幸いです。

補足

> あと一つ考えたのが、ホスト側PCでLive CD版Linuxを立ち上げて、HDDの
> 空き領域にNTFSではなくext3(できればext4)のパーティションをこさえて、
> それをゲスト・ホスト双方でマウントする方法。

良く考えたらWindows上のext4パーティションをゲストであるCentOSから
どうやって見るんだ、って話になるので、この話は詰みですね。

となると残るはDropboxかSambaの二択になるか……。