タグ: git

使えるねっとからサーバーの引っ越し

使えるネットのサーバーからさくらインターネットにお客さんのサイトを引っ越しする作業を進めています。お客さんのサイトは、使えるネットのVPSの中で別ドメインで運用していたもので、最初にこちらから抜き出して引っ越しをしてしまいます。

決してここでは、使えるネットのサーバーが使えないと言っておらず、自分の作業ミスというかインストールミスというか、いろいろとサーバーに問題が起こってきそうなので、早めに引っ越したほうがいいという決断となりました。そもそも、CentOSの一つ前のバージョンだからWordPressの最新バージョンに対応できなくて、最新バーションに対応するためにいろいろと環境を設定しだしたらコントールパネルがその環境に対応していなかったということで、使えるネットのせいではなく私が悪いのです。Pleskが使いにくいとか、たまにアクセスが重くなるとか、マニュアルが煩雑でわかりにくとか、いきなり英文のメールが届いてその対応の情報がないとか、いろいろありますが、なんだかこれではますます使えるネットは使えないということを暗に言っているようで誠に恐縮です。サポートに連絡すると中1日で回答が返ってきますので、サポートの対応は素晴らしいのです。

お客さんのサイトはメールフォームで送る処理があるくらいで、そんなに引っ越しには面倒がないのですが、ローカルのテスト環境を揃えるところで時間がかかってしまいました。とにかくEclipseの3.7のINDIGOに付いてくるEGitはWindowsでは使えないということをここでメモしておきます。commitの挙動がおかしい。自分のところだけかも。仕方ないので、Eclipseを3.6に戻してしまいました。こちらは問題なくgitを使えます。

ローカルでメールを送信するような環境がなかったので、XAMPPに付いてきたMercuryでGmailにメールを転送するように設定してみました。こちらは使えます。

以上、今日の作業のメモ書きでした。

震災で、特に停電で対応したこと。

今回の震災では、私は横浜でしたので直接の被害には会いませんでしたが、そのあとの計画停電の影響が大きかったです。

まず、震災から対応したとことは、起動しているPCを減らしたことでした。なるべく身軽になることでした。今まではVistaとWindows7の2台のPCを起動したままにして、プロジェクトごとに使い分けていました。今はWindows7のPCのみにまとめています。サーバーは今まで通り起動したままですが、再起動後の復帰も短くするように手順をまとめています。

プログラムを仕事として開発していますので、作ったソースプログラムが消えて無くなるのはとても困ります。今回からソースファイルの管理も変えました。今まではSubversionでローカルのサーバーにリポジトリを集中して置いていましたが、今はGitで開発しているPCでリポジトリを分散させています。git-svnでSubversionからGitへの移行は思ったよりも簡単です。停電になるとサーバーが使えなくなりますし、その後に復帰も時間がかかります。万が一サーバーが起動しようとしたときに起動できないことも考えられますので、Gitの分散管理は助かります。どこかのPCでGitのリポジトリが残っていれば、ある程度の復旧は可能で完全に消失というのもありません。バックアップリポジトリをGitosisで借りている外部のデータセンターに作りましたので、ローカルのサーバーが起動できなくてすべて消失というのも防げます。Gitosisは簡単にリポートのリポジトリをGitで管理できます。Gitは便利で安全ですが、習得に時間がかかります。最近はWindowsでTortoiseGitのような便利GUIのツールが出てきましたので、今までのようにコマンドラインでコマンドを叩くということも無いので（でも、いざというときにはGitのコマンドを叩く必要があるかも）Gitの敷居が低くなってきました。Gitは今回の震災からのお勧めソフトです。

[amazonjs asin=”4863541465″ locale=”JP” title=”開発効率をUPする Git逆引き入門”]

社内のサーバーに頼らなくなったいえば、ドキュメント類はすべてDropboxに置いてからサーバーでドキュメントを共有することが無くなりました。メールは以前からGmailに移してしまっています。したがってローカルのサーバーがなくても、ドキュメントとメールは何とかなります。しかし、たまにGmailは重くなりますので、この辺りは対策が必要です。

[amazonjs asin=”B00JYSCL5G” locale=”JP” title=”知らないと損する！Dropbox厳選テクニック27 (impress QuickBooks)”]

完全にローカルのサーバー無くなるかというと、どうしても写真のファイルは大量にありますので、ローカルのサーバーをなくすことができません。写真のファイルは８０Gバイトほどありますので、ファイルをクラウドサービスに置いておくと有料のサービスを契約することになります。費用の面で考えると別の場所の社内サーバーにバックアップを格納するようにしています。サーバーが故障してしてしまうと困るので、バックアップは別のサーバーに転送するようにしています。念のために事務所内の別のサーバーにもファイルをrsyncで同期していますので、都合3カ所にファイルが存在していることになります。

後のサーバーの対応としては、UPSでの電源確保の確認です。もちろんサーバーにはUPSを接続しています。停電となってサーバーを停止しなければいけないときに、モニタもUPSに接続しておくことを忘れないことが必要です。iSCSIのTeraStationISもつながっていることから、途中のハブもUPSで電源が供給している必要もあります。初めての計画停電のときに、必要な機器に電源が入っていなかったので、シャットダウンするときに慌てました。正しくTeraStationをシャットダウンできなかったようで、起動したときにディスクの同期にとても時間がかかりました。

[amazonjs asin=”B002GK2PR8″ locale=”JP” title=”APC RS 550電源バックアップ(500VA) BR550G-JP”]

今回PCにつないでいたUPSは故障してしていました。UPSをつないで立ち上げようとするとPCが起動できなくなりました。これはAPCのUPS特有のバッテリーの突然死のようです。以前からAPCの製品やサポート対応に問題があるので、もうAPCのUPSは導入する気はないでしょう。他社のUPSを探さなければいけません。

その他UPSの対策としては、停電になったらサーバーを自動機にシャットダウンするようにしています。APCUPSDをCentOSのサーバーにインストールして、一定時間停電したら自動シャットダウンするようにしてます。

気のせいですが、震災から東京電力の電源供給が安定していないようです。電圧低下のせいで、たまにUPSに一瞬切り替わります。２，３秒で復帰するのですが、あまり気持ちよいものではありません。瞬断を防ぐことから、今はUPSにつなげておく必要があります。

結局の所は、当たり前のことですが、サーバーは壊れても大丈夫のようにバックアップが重要ということになります。大きな震災を考えると一カ所の場所が被害にあっても他の場所で助かるように、ファイルを分散させるようにします。バックアップという作業は面倒なので、定期的に自動的にやってもらうしています。どのように運用されているかを後でわかるようにメモと手順書を残しておきましょう。いざとなったときに接続状況を忘れてしまいますので。

[amazonjs asin=”B002RL96MS” locale=”JP” title=”BUFFALO iSCSI対応 Tera Station IS ラックマウントモデル4.0TB TS-RIX4.0TL/R5″]