Monthly Archives: 1月 2015

lsyncdで複数サーバーをターゲットに同期する際のtips

By | 2015/01/27 7:03 PM

佐々木です。

前回に引き続き lsyncd に関するtips
lsyncdで複数サーバーと同期を行う場合、下記のような設定をよく見かけます。

これは次のように書き換えることができます。

同一設定をまとめることでスッキリしました。
上記で大分見通しがよくなりメンテナンスが行い易くなりましたが、できれば同期先の設定リストを別ファイルとして分けて読み込めるようにしたいものです。

lsyncdの設定ファイルはlua言語で書かれたコードであるため、プログラムを記載すれば実現可能です。
以下にサンプルコードを記載します。

/etc/sync-server.list には同期先のIPアドレスを記載します。


xxx.xxx.xxx.xxx
yyy.yyy.yyy.yyy

設定ファイルと思っていたものがプログラムになってしまいましたが、上記のようにしておけば何か別のバッチなどでIPアドレスのリストを吐き出せるようにするだけ同期先を追加できるようになります。

以上、ご参考になれば幸いです。

lsyncdを使う時はtimeoutを設定しましょう

By | 2015/01/26 11:50 PM

はじめまして。佐々木です。

ブログ書くべきと言い出したわりに、なかなか投稿しない悪い奴という汚名がつきそうになったので、とりあえず軽いネタをご紹介したいと思います。

lsyncdを実運用していると一時的なネットワーク通信断などが発生した場合、稀にrsyncプロセスが途中で止まってしまい、残ってしまうことがあります。
この現象が発生すると、次にファイルが更新された時でも前のプロセスが終わるまで待ち状態となり同期が停止してしまいます。

この問題はrsyncのオプションでtimeoutおよびcontimeoutを指定すると回避することができます。
lsyncd.confから設定する場合は、_extraで指定すればよいです。

以下に、設定例を記載します。

–timeoutは転送のタイムアウト値。–contimeoutはrsyncデーモンに接続する場合のタイムアウト値です。
上記設定を行っておけば、何らかの状況により同期が止まってしまった場合でも、指定時間でタイムアウトが行われ継続して同期が行われるようになります。

以上、小ネタではありますがlsyncdに関する設定のご紹介でした。

ソケットでメールを送ってみよう

By | 2015/01/23 9:06 PM

まぁ、phpならメール関数使うなり、ライブラリいっぱい転がってるんで
そういうの使ったほうがいいです。
当然。

ただ、SMTPの生コマンドで送ってみよう というだけの話です。

前提条件として、認証なしのSMTPサーバがローカルにある という前提。
認証ありの場合、HELOコマンドをEHLOに変えてごにょごにょして下さい。

本当は$ret部分でコマンドの結果を受け取って、失敗したとかの判定を入れるべきですがめんどくさいので
割愛。

あと、どうせソケットで送るなら、一回つないだコネクションを使いまわして連続で送信する ということをやってます。
phpのmail関数系は毎回コネクションを張るので、大量に送るならコネクションは使いまわしたほうが良いです。

まぁ、大体のライブラリにはアリます。

ただ、注意がアリます。
大量に送信していると、途中でコネクションが切れたり ということもあるので、
ちゃんとコネクションがはられているか ということも確認しましょうね

大体2~300回ぐらいで 貼り直したほうがいいと思います。

CSSやJS等が更新してもキャッシュされてしまって困っちゃう!

By | 2015/01/19 8:29 PM

と、言うお話。

的な感じで書けばキャッシュされなくて済むね!
やったね!!

とは行かないですよね。
コレだと普通に更新していない時でも毎回転送してしまうので。

ではでは

って感じにすればいいんじゃね? 俺って天才!

とか思っちゃう早とちり君もいますね。

phpのマニュアルにも書いてあるんですが、filemtime 関数の結果はキャッシュされるのです。

注意: この関数の結果は キャッシュされます。詳細は、clearstatcache() を参照してください。

なので、定数でも作っちゃいましょうか。

んで

ってしてやるのが確実かなと。
CSSとかJSを更新したタイミングでインクリメントしてやれば良いかと。

デプロイツールに上の定数をインクリメントするような仕組みを入れてやれば、
更新した時に自動的にタイムスタンプが変わるかなぁと。

spl_autoload_registerでrequire_onceだらけのソースをスッキリさせましょう。

By | 2015/01/16 8:28 PM

便利ですよね
spl_autoload_register

newした時にそのクラスが無ければ探しに行ってくれる というような感じです。

ということで簡単な使い方です。

document_root/
 ├index.php
 └class/
    ├Hoge/
    │ └hoge.class.php
    └Fuga/
      └fuga.class.php

的な感じのファイル構成だとしましょうか。

って感じにしておけばOK。

また、
require
する時に

みたいな事してやれば、デバッグで$autoload_listを出力させてやれば、どんな順番でclassが読まれてるか分かる。
で、file_existsのif にelse付けてやって

ってしとくのもありっちゃ有りです。
(try catch で例外受けるほうがいいと思うけど割愛)

spl_autoload_register部分を共通ファイルとかにしちゃえば、classのロードのためにいちいちrequire_onceとかしなくて済みます。
クラスの命名規則と設置場所さえルーリングされていれば、requireが100個あろうが200個あろうが書く必要は無いです。

WebアプリケーションからMySQLのクエリ発行する際に入れておくといいかも知れない

By | 2015/01/05 11:01 AM

WebアプリケーションからSQLを発行する際に
入れておくといいかも知れないので紹介

WebアプリケーションからSQL実行する際に
どこから呼ばれて、何処のメソッドかわかるようにしたいので
db.phpクラスに以下のような感じにしておく。

やってる事は単純で
呼び出し元のファイル名とファンクション名を取り出してるだけ。

コレを発行するSQLの頭に付けてやり、末尾に改行を入れてやればそのままクエリは発行できます。
そうすると、mysql側で

とかすると

的な結果が見れるのでいかがでしょうか。

トラブルや、高負荷時に何処のクエリが原因かすぐさま確認したい! といった時や
結果取れてるけど、このSQLは何処から呼ばれてるんだろう?
といった時に役にたつと思います。

的な機能があれば、デバッグ時にも当然役に立ちますし。