きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

jythonスクリプトの日々

ファイアウォールのカスタムルール用ファイルを作成するjythonスクリプト、凡ミスしてたがなんとか直した。


DNSがいないせいもあり、/etc/hostsに書き込まないとdmgr起動しないのは大変だった。
DCSとか出てたからファイアウォールをミスったのかと自己暗示にかかった。


最終的にはファイアウォール設定にこぎつけた。

ls /etc/sysconfig/ipv4_filter_addon_was_* | xargs -i lokkit --update --custom-rules=ipv4:filter:"{}"

jythonでファイルを作ってあげるときは、-connType NONEで構わない。AdminConfigしか使ってないので、Dmgr01プロファイルでやれば問題ない。


その他、グローバルセキュリティのユーザーレジストリをローカルOSに変えたり、
sdkを7にしたり、
J2C認証エントリを作ったり。。。


すごいゴミだらけの昔の設定を見ながら、
新しく作る環境を全部スクリプトで書く。


相変わらずJDBCプロバイダーの作成は面倒臭い。
pdqないから、クラスパスから削ったのに、管理コンソールのコマンドアシスタントは、削ったものをぶちこんできた気がする。戻るボタンでも押してたっけな。。。
あと、ユニバーサルドライバーパスもWebSphere変数にされてるのだから、入力項目を画面にだしてほしいもんだ。サーバースコープだとダメなんか?
それはそれとして、結局WebSphere変数を設定するコマンドアシスタントはでてこないので、別途書く必要がある。
variableMapからエントリ探すコードは面倒臭いんだよ、書けるけどさ。


SDKを変えるのは、次のコマンドを使うことにした。
AdminTask.setNodeDefaultSDK()
オプションの-clearServerSDKsの挙動を見ておきたい。きっとクリアするだけじゃなく、ちゃんと新しいのに設定してくれるよね。
ノード名は、AdminConfig.list('Node')して、スプリットして、ループさせて、ごにょごにょ。
オプションの-sdkNameを使うつもりだが、値はまだベタ書き。
AdminTask.getSDKVersion()にオプション-highestを付けて、どんな文字列が返ってくるかで、そこもベタ書きをやめられる気がしている。


いま書いてるスクリプトは、汎用性に欠ける。
ただの関数だけでは変更に弱いというか、見通しが悪い。
クラスにしたい。
visitorパターンとか使えないかな。
ベースとなるトポロジ、特にセル名、ノード名があり、そこから追加するトポロジ(クラスター、サーバー)があり、個々のスコープで行うことを書く。
トポロジ側にacceptを書いてくイメージかな。


def accept(self,variablevisitor):
  variablevisitor.visitCell(self.getCellName())
  for node_name in self.getNodeNames():
    variablevisitor.visitNode(node_name)
  #endfor
 ...
#enddef


全てのノードに同じ設定をするならいいけど、バラついた設定にしたい時には厳しいかなぁ。でも、コードからトポロジを分離できる方が嬉しいんだよな。


んー、ダメだ。これは破綻する。
とくにクラスタで破綻する。
クラスタは大抵用途が違ってくるので同一設定とかありえない。


トポロジー分離は残しつつ、別の方法を模索。
topology = Topology()
topology.addProperty(('hoge_path','/opt/hoge')
cell=topology.addCell('mycell')
cell.register(func_mycell_decorator)
dmnode=cell.addDMNode('mydmnode')
mynode1=cell.addNode('mynode1')
mynode1.register(func_mynode1_decorator)
myserver1=mynode1.addServer('myserver1')
myserver1.register(func_myserver1_decorator)
topology.build()

トポロジ、セル、ノード、サーバ、クラスタは、クラスにする。
配下を作成(add)するときに、Topologyは伝播させて保持させる、セルはノードとクラスタも保持、ノードはサーバを保持。(利用するシナリオはなかなか思いつかないけど)
これらのクラスはデコレーターパターンっぽい扱いだが、デコレーションの仕方は、パッケージを工夫して関数登録にする。たぶん出来るはず。
プロパティーを個々のクラスが持てるようにする、使うか使わないかは関数次第。
個々のクラスのプロパティーにない場合、トポロジのプロパティーを見るようにする。
プロパティーはほとんどWebSphere変数の用途だが、だからといって一つ上のスコープを探すのはちょっと違うだろう。クラスタならまだしもノンクラスタで、一つ一つのサーバーに登録するのが面倒な値だとか、本当ならノードごとに違うかもしれんが、同一ホストの複数ノードみたいな垂直っぽいときに、同一ホストのファイルパス変わるわけないみたいなのを二回書くのが嫌だなって思ってのことです。


デコレーションを関数にしているので、
メイン実行できるようにもしておく。
例えば、サーバに登録する関数は、サーバクラスからサーバ自身を受け取るが、ノード名とサーバ名を取り出してすぐに他の関数コールする想定。なんかこれ考えてる段階ですでに設計バクしてそうな予感は漂ってきている、クラスに登録しといたプロパティーが渡せてなーい。ま、一旦置いておこう。どの種類の引数使うかも悩んでるところやし。
if __name__ ==__main__の判定ののち、引数解析して単独実行(他の関数のほうを呼ぶ)もできるようにしておく。単独とはいいつつも、きっと1ファイルでは動かないんだけどな。


このデザインにも課題がある。
ノード内サーバへの一括登録や、クラスタメンバへの一括登録は、サーバの設定よりも優先すべきか否か、順序の問題がある。


それと、クラスタの作成順序もある。
1つ目のメンバのコピーを2つ目のメンバにしたいというなら、先にサーバ設定を仕上げておかないと嬉しくない。ああ、でも、後から追加でもいいのかな。後からと言ってる時点、やっぱり順序を意識してるじゃないか。


パッケージのイメージ。
ショートホスト名.cell
ショートホスト名.cell.node1
ショートホスト名.cell.node1.server1
ショートホスト名.cell.cluster1
ホスト跨ぐ水平クラスタになると破綻するじゃないか。
やっぱり、セル名でいくしかないかな。
同一のセル名がでてくると困るんだよね。
んー、やはりショートホスト名でいく、dmgrがいるところのショートホスト名だ。
ホスト名同じでIP違うとかはしらん。


ほかに考えることは、ログとsave()タイミング。
バージョン的に使えるのなら、loggingを使う。
pythonにはある。WAS付属のjythonバージョン次第、けっこうギリギリのラインだった気がする。
AdminConfig.save()を細かくやるか、スコープでやるかみたいなストラテジを入れたいところ。それやると、引数が多くなりそうで嬉しくはない。コードの中の色んなところに判定が必要になって汚くなりそう。


wsadminlib.pyは知ってるし、使ったこともあるが、書いてるコードが構造的にエクセレントになるわけではない。もちろん雑多なコードを省略できることは確かなんだが、どこに何を設定しているかを分かりやすくするには別の取り組みが必要だと考える。


日を跨いで、、、上記のようなデコレーターパターンっぽいコードは実際に動作するように組み立てることはできた。
だが、書き進めてるうちに別の問題が。
続きは別のエントリで。