ローファイ日記

出てくるコード片、ぼくが書いたものは断りがない場合 MIT License としています http://udzura.mit-license.org/

ソフトウェアをリプレースする前に考える三つのこと

個人的には三つの基準があるという話。

  1. そのソフトウェアが十分に古く、十分長い間保守されていないか
  2. そのソフトウェアを触れる人間が組織内に少なく、増やす手だても困難であるか
  3. そのソフトウェアで実現できることが、他の新しいソフトウェアでより容易に実現できるかどうか

1. についてはそうだろう、という感じだと思う。というかリプレイスの前提になると思う。バージョンが古いソフトウェアを使い続けると、脆弱性も出てくるし、一般的には開発の速度も低下する。

ただ、ここで重要なのは、2.3.との兼ね合いかなと思っている。

例えば2.1.より優先される場面というのもあるだろう。Hoge言語で作ったミドルウェアの保守について以下のような状況にあるとする。

  • 開発者が退職してしまった
  • Hoge言語に関するドキュメントが全然なくて学習が困難

という感じであればリプレースは検討に入れていいかもしれない。

しかし、ここで3.の観点も大事で、例えば古いからといってcronやlogrotateやらを別のミドルウェアにリプレースしようとする人はいないと思う。こういう場合は古い、ではなく枯れている、と呼ぶ。

とはいえ、最近のLinuxミドルウェアなんかを見ていると、枯れ果てたソフトウェアを平気でリプレースしかけてくる印象があり(典型的にはchronyやsystemdの登場)、もっと頭を柔らかくしないといけなそう。やっぱり「新しいソフトウェアでより容易に実現できる」のが大事なんだろう。

話戻って、ミドルウェアと違って言語に関しては、「変更し続ける」という観点が出てくるので、「枯れている」ことのメリットが少し小さくなる。例えばHoge言語に固有の優れた点があるのであれば(Erlangとかが連想されそう)頑張ってHoge言語を学習する方向でもいいと思うし、Hoge言語自体が古ければバージョンの高いHogeで書いても違うFuga言語で書いても書き直しという点では同じだろうし、そもそもそのミドルウェアを捨ててしまうのもアリかもしれない。


ここで感心しないパターンというのもあって、特に「自分がよく知らないからリプレースする」というのはあまりいい結果を生まない気がする。リプレイスはなんだかんだ多大なコストがかかるので、無知より、まだ好悪とか情熱とかでドライブされている方がうまくいくんじゃないだろうか...と思っている。

というのも、既存の技術情報について調べない、ということは、既存の 仕様 についてもよく調べずに思い込みで変更をぶっこんで意図しないトラブルを起こしがちな技術者の傾向の表出だと思われる。リプレースなので、トラブルは起こるだろうけれど、そういうものはコントロール可能な状態で起こさないといけない。

リプレースは大変だし、正解もないものなので、まずは冷静さが欲しいと思う。多分、0番目の基準が実はあって、「既存のシステムに対してリスペクトを持っている」という項目が必要なんではないか。

なお、やるな、という意味ではない。こういうことを言っておいてなんだけど、諸々コントロール可能なら積極的にやるべきと考える。

参考記事

myfinder.hatenablog.com

  • 何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること
  • ボトルネック以外触らない

至言。とはいえぼくは情熱とかその辺も許容するけど...。


どこぞでポエんだけど、せっかくなので書いてみる(たまには作った自慢じゃなくてウダウダとした考えのdumpもいいじゃない)。

最近書いたやつ @2015-10

monkfish

github.com

OpenStack環境で、テナントに所属しているインスタンスのネットワーク情報を参照して /etc/hosts を自動更新するやつ。内部DNSが使えないような構成の場合に便利かもしれない。

もともと、 id:lamanotrama さんのPerlスクリプトAWS向けの同じようなものがあって、それをGo言語でクローンして、それをOpenStackポートした。 gophercloud 最高だ!(ロゴが)

http://gophercloud.io

puppet-report_slack2

github.com

minne というプロジェットで雑に描いたPuppetのスラックレポーターを切り出した。こういう通知が来る。これは便利だと思う。

hi

「2」になってるのは、先行して同じようなモジュールがあったからだけど、それは動かなかったので自分で低依存で書き直した。puppetmaster/puppetserverどちらでも動く。Puppetのバージョンも2/3/4と動くと思われる(Ruby 1.8環境でマスターをあげている場合は、明示的に gem install json したほうがいい。というかREADMEに書こう。。)。

そういえばペパボに入っていつの間にか2年が過ぎた

udzura.hatenablog.jp

ペパボに入ってからのほうがアウトプット増えたのは間違いない。東京、福岡関係なく、毎日がチャレンジ(普通の意味で)です。

元気にやっております。


便利なリンクを共有します。僕と一緒に 106 South Indian に行きましょう

「やわらかConsul」というワークショップをした

社で、徐々にConsulへの依存度が上がってきたので、Consulパーソンをより増やすべくワークショップを開催した。

gistを公開します。

サンプルプロジェクトは以下。Vagrantのプロビジョナでポンポンとステップを進められます。

github.com

Consul、機能が多いけど、クールなこともできるので、知っていることはどんどんドキュメントにしていこうと思いました。

OpenStack 上にある MySQL のデータを、ファイルベースでサーバAからサーバBに復旧する手順

  • ある日、 OpenStack にあるサーバAが起動しなくなった :sob:
  • OpenStack なのでディスクイメージは見ることができる

という状態。起動しないので mysqldump のようなコマンドは使えないが、以下のように復旧した。

同じアーキ、同じOSでサーバを作り直す

Puppetなどでサーバ構成管理していればなんちゃないですね。していない場合は... ......

サーバAの母艦ノードに入る

いわゆる、compute nodeというもの。

拡張の種類にもよるが、 nova show などで確認できるはず。また、一緒に instance_name というものも確認できる、控えておく。

$ nova show test001
+--------------------------------------+------------------------------------------------------------------+
| Property                             | Value                                                            |
+--------------------------------------+------------------------------------------------------------------+
...
| OS-EXT-SRV-ATTR:hypervisor_hostname  | comp-node0014.example.cloud                                      |
| OS-EXT-SRV-ATTR:instance_name        | foocloud01-0000063b                                              |
...

入ったら、 guestmount というすごい便利そうなコマンドがあって、それでサーバAのブートディスクをマウントできる。

root@comp-node0014:/# instance_name=foocloud01-0000063b
## /var/lib/nova/instances/${instance_name}/disk にあるはず
root@comp-node0014:/# mkdir /tmp/${instance_name}-work
root@comp-node0014:/# guestmount --ro -a /var/lib/nova/instances/${instance_name}/disk -m /dev/ubuntu-vg/root /tmp/${instance_name}-work

マウントできたら、 chroot なりなんなりでサーバAのファイルシステムがどうなっていたか確認できる。

ここで、mysqlの既存のデータを持ってくる。

# chroot /tmp/${instance_name}-work
root@comp-node0014:/# cd /var/lib
root@comp-node0014:/var/lib# tar czvf mysql.tgz mysql/                                                                                                                   
mysql/
mysql/ibdata1
mysql/ib_logfile1
mysql/auto.cnf
...
root@comp-node0014:/var/lib# exit

## 見える箇所にコピー
# cp /tmp/${instance_name}-work/var/lib/mysql.tgz ./
## umount忘れない
# umount /tmp/${instance_name}-work

サーバBのmysqlデータを置き換える

このデータをアップロードした前提で、以下は新サーバでの操作。

## mysqlを止める
ubuntu@serverB:~$ sudo systemctl stop mysql
## 持って行ったら /var/lib/mysql を差し替え
ubuntu@serverB:~$ sudo mv /var/lib/mysql /var/lib/mysql.bak
ubuntu@serverB:~$ tar xzf mysql.tgz 
ubuntu@serverB:~$ sudo mv ./mysql/ /var/lib/

ただ置き換えただけでは認識しないので、 mysql_upgrade の実行。

ubuntu@serverB:~$ sudo mysql_upgrade -u root -p
Enter password: 
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
Warning: Using a password on the command line interface can be insecure.
Running 'mysqlcheck with default connection arguments
Warning: Using a password on the command line interface can be insecure.
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
...

sudo しているのは、 /var/lib/mysql/mysql_upgrade_info というファイルの読み書きができるユーザでこのコマンドを実施する必要があるため。mysql的なユーザは関係ない。

終わったら、mysqlを立ち上げ、mysqlクライアントからSQLなどでデータの復旧を確認する。

ubuntu@serverB:~$ mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 23
Server version: 5.6.25-0ubuntu0.15.04.1 (Ubuntu)

Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show tables;
ERROR 1046 (3D000): No database selected
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| foobar             |
| mysql              |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)

お疲れ様でした。

参考です

Hacker TackleでHashicorpツールについて話した

hackertackle.github.io

話しました

www.slideshare.net

最近とにかくPackerとConsulを触っていたのでそのお話をし、その後、なぜ僕がこのようにYak刈りに突っ込んでいくかのお話をしました、が、当日は50分を若干オーバーし、後半(後半が一番大事なのに)は駆け足となってしまいました......すいません。

50分で180枚目のところぐらいまでは話せたので、今後はこれをベロシティの基準にしたいと思います...(?

当日の話

正直発表前はそわそわして集中できず、発表後は放心演義といった趣きだったのですが、松本さん、ばりかた勉強会の花田さんのお話などを聞いていました。

懇親会では、おひさしぶりに id:repeatedly さんとお話できたり、 id:kyon_mm さん、 id:daiksy さんといった以前よりお話したいと思っていた方々と初めて話せたり、非常に楽しく過ごせました!

運営の皆様ありがとうございました。福岡でもこんな感じのキレキレなイベントをもっと増やしたいですね。

その他の登壇者の皆さんへリンク

hb.matsumoto-r.jp

daiksy.hatenablog.jp