2014年3月30日日曜日

vagrant覚書

あちこちで仮想環境構築ツールのvagrantについて書かれてますが、操作コマンドと実際のデータファイルの関係を調べたので記録しておく。(応用きかせようとするとき、実際の仮想マシンのディスク等がどうなっているか理解しておいた方がいいので)

仮想マシンは昔からつきあっていますが(この世界では有名なVMwareが1.5の時から使っていました。当時英語のHPを一生懸命読んで、DL販売で購入しました。)、色々な実験をするときいちいちPCを準備しなくてもいいので重宝してました。しかし仮想マシンの構築はそれなりの手間がかかり、慣れてない環境を構築しようとして失敗したときなどは、再度仮想マシンの構築からやった方が早い時が多く、大変でした。(仮想マシンのディスクイメージのsnapshotや、コピーを保存しておいたりして、再構築しなくてもいいようにしましたがGB単位のデータ量になるのでコピーだけでも結構時間がかかります。)その点vagrantだとテンプレートがあればコマンド一発で仮想マシンのセットアップをしてくれるので、心置きなく環境構築を試すことができます。(といっても基本GUIなしの環境ですが)一通り手順と、よく使うコマンドの簡単な説明一覧を示しておきます。

1.Virtual Boxをインストールする
(個人的にはVirtual Boxにはあまり良いイメージは持ってません。発表当時はVMwareに比べて実行速度がかなり遅く、すぐに使わなくなってしまいました。今回改めて使ってみましたが、随分早くなったな〜という感じです。vagrantが基本的にVirtual Boxのテンプレートが多いので、こちらでいきます。)

2.vagrantをインストールする

3.テンプレートの準備
vagrant box add (テンプレート名) (URL) ;仮想マシンのテンプレートを取得する(今後、引数のテンプレート名で操作する)
list ;システムにインストールしてあるテンプレートの一覧
remove (テンプレート名) ;テンプレートの削除

4.仮想マシンの構築(仮想マシンの設定ファイル:Vagrantfileの場所で下記のコマンドを実行)
vagrant init (テンプレート名) ;vagrantの初期化(Vagrantfileの作成)
up ;仮想マシンの起動
ssh ;仮想マシンと接続
status ;仮想マシンの状態
suspend ;実行中の仮想マシンの一旦停止
resume ;一旦停止した仮想マシンの実行
status ;仮想マシンの状態
reload ;仮想マシンの再起動
halt ;仮想マシンの停止
destroy ;仮想マシンの削除(Virtual Box上の仮想マシンが削除される)

5.テンプレート・データの保存場所
~/.vagrand.d/boxes/(テンプレート名)
基本的にはvirtual boxの仮想ディスクイメージが入っている

6.vagrant設定ファイル
~/(任意)/Vagrantfile
仮想マシンの起動等を行う場所、任意のパス名を自分で設定する。
initコマンドにより作成される。

7.Virtual Boxの仮想マシン
~/VirtualBox VMs/(仮想マシン名)
初回のupコマンドで作成される。
vagrant設定ファイルのパス名を頭文字として、仮想マシン名は作成される。
vagrant設定ファイル毎に仮想マシンの実体は作成されるので、一つのテンプレートから複数の仮想マシンを作成・実行できる。

今回、UbuntuとMacの両方でvagrantを試してみましたが、全く同じような動作をしてくれました。(Rubyベースで作成されているとのことですが、それでも異なるOSで同じように動いてくれるというのはなかなか無いことです。)
仮想マシンの作成/起動は、5.、6.、7.の順番に行われますが、それぞれのコマンドで作成されるデータ、およびその関係を下図に示します。

説明を聞いて、最初の1個の仮想マシンを起動するまではなんとなくわかった気になるんですが、いざ複数の仮想マシンを起動したい、同じテンプレートで複数の仮想マシンを動かしたい、と考えたときどうなるんだろうと思い、データがどこに保存されているかまとめてみました。
従って、調子にのって多数の仮想マシン、テンプレートを作ると、~/.vagrant.d/以下、~/VirtualBox VMs/以下のHDD容量が大変なことになりますので注意しないといけません。

後、使っていて気づいたんですが、CentOSのテンプレートから作成した仮想マシンにおいて外部へのポートが閉じた設定(今のクライアント指向のデストロはこれが基本です)のままテンプレートが作成されていたものがありました。そのため$ vagrant sshで仮想マシンに接続はできますが、ping等まったく通らず、サーバーの実験をしようと思う時、ちょっと面倒くさいです。(逆に、vagrant sshはどうやって接続しているんだろう?と思ってしまいます。)

PS.
上記、仮想マシンの外部との接続ですが、その後CentOSでも設定でpublic_networkを一度有効にして新しいethのルート(仮想マシンに対するネットワークデバイス?)を設定してくるか聞いてきた時、有効にしたら仮想マシン上で新しいeth1が認識されるようになり、CentOSでも外部からのpingに応答するようになりました。(これは複数のEther HWがMacにあったためのようです。Ubuntuでは聞かれませんでした。)
その後はpublic_networkを無効にしても外部(host PC)からのpingは通るようになったままになりました。Virtual Boxのネットワークデバイス周りの設定を変更してしまったようです。

2014年3月22日土曜日

Nexus7(2012) 4.4.2の調子があいかわらずいまいち

初代Nexus7のOSが4.4.2になりましたが、WiFiの調子はあいかわらずです。

・Sleepに入っているときに、時々WiFiの親機を忘れて(?)WiFiとの接続が切れている
・WiFiの親機のキーを忘れて、以前接続できていたのが再度キーを入れないといけない

Sleepから起きる時もなんかもっさりしてるし、使い勝手が悪くなった?
ただWiFiのキーを忘れることですが、どうもWPSで接続している親機のキーを忘れるようです。(家にはWiFiの親機が1Fと2Fで個別に存在しており、1FだけはWPSで接続設定しています。2Fの64bitのキーを手入力した方には、この現象がでていません。)このNexus7も購入してから一年半たち、結構よく使ったせいか最近はバッテリーの持ちが以前より悪くなった気がします。(バッテリーはやはりiPadの方がいいですね)

PS:
最近は更に状況がひどくなり、sleepしてると勝手にWiFi Offになってしまい、通信しなくなってしまいます。しかも電源Onしてもどこの親機も捕まえなくなり(暴走してる?)、ネット関係の操作が何もできなくなってしまいます。timeOutを待つのが面倒くさいので、そういう時は電源Offして強制再起動するようになってしまいました・・・ 今の4.4.2、調子が悪いよ〜早く更新してくれないかな。(GoogleがリファレンスマシンとしてるはずのNexusでこれではちょっとね〜)

2014年3月13日木曜日

Androidアプリ開発:ADT eclipseの更新 新規プロジェクトの作成が???

この間のAndroid SDKの更新からActionBar用と思われるライブラリプロジェクトが、新規のAndroidプロジェクト作成時に作られてしまうという状態になってしまいましたが、それ以外にもプロジェクト内にデフォルトでsupportライブラリが作成されるようになってしまったようです。(別に害はないんですが気持ち悪い)

1)作成時
ライブラリが作られています。(作成時に、テーマをnoneにしたんですが、styles.xmlにはActionBarが入ってしまっている様子)

2)読み込み時
上記をいったんgitに登録、それを再度読み込んでプロジェクトを作成してみますと以下になります。
ライブラリは特に作成されませんし、普通に動きます。(もちろんこのアプリは簡単なサンプルで、ActionBarは使っていません。)

何かバグっぽい気がしますが、とりあえず問題はおきません。どうも新規プロジェクト作成時のテーマ選択がうまく機能していない気がします。(機能てんこ盛りの状態でプロジェクトを作成してしまう感じ)

2014年3月9日日曜日

Androidアプリ開発:Nexus7でアプリのロード・デバッグができない状態

Androidアプリを作るとき、よくNexus7でデバッグします。ただ以前からNexus7を接続してもeclipseのデバイスリストに表示されないことがちょくちょくあり、その度に開発者向けオプションからUSBデバッグをOn/Offしたりしてましたが、この間再起動しようが何しようが使えない状態になりました。

昔のAndroidはUSBデバッグのOn/Offと「USBストレージとして使用する」が連動していたんですが、Android4.0からUSBストレージがMTP(メディアデバイス)になり、そちらのOn/Offとは独立になったようです。そのためUSBデバッグをOn、かつMTPもOnという状態が存在します。そうなると基本的にはMTPが優先されてPCからはNexus7内部のストレージにアクセスできますが、ややこしいことにNexus7の方ではUSB接続時にUSBデバッグに接続されましたと、画面上部に表示されあたかもデバッグできるような錯覚に陥ります。
eclipseでデバッグに使用するときにUSBストレージとしてPCから見えたらおかしいので、そのときは設定>ストレージからメニューでMTPをOffにしないといけません。
しかしなんでこれ、USBデバッグと連動するのやめちゃったんだろう。しかもこのフラグ、時々気づかないうちにOnになっていることがあります。おかげでこれまで時々、Nexus7がeclipseから見えない状態になり苦労しました。

2014年3月8日土曜日

Androidアプリ開発:ADT eclipseの更新-appcompat_v7プロジェクトが勝手に作られる!?

ネットでちょっと動かしてみたいアプリのソースがあったのでADT(eclipse)をMacで起動、念のためSDK Managerで更新ライブラリを確認してみたら、新しいのがでてました。いやな予感がしたのですが、念のため更新。するとSDK manager本体も更新しろといってきます。これはeclipseの方から行いますが、その後どうも動きがおかしくなり新規Andoidプロジェクトがうまく作れなくなりました。

色々やっていたので何が原因で、何が起きたのかはっきりしませんが家の中にある他のMac、およびWindows7のADTも更新してみて動作を比較しながらやり、どうにか3台の環境で元々動かしてみようとしたAndroidアプリのソースを動かすことができるようになりました。(SDK Manager本体の更新にAndroid Developper ToolsサイトのURLが"http"ではだめで、また"https"に戻したり・・・、いったいどちらが正解なんだろう?時々、片方ではエラーがでて、片方で更新がうまくいったりします。)

ただ、なんか今度の更新でADTで新規Androidプロジェクトを作成すると、"appcompat_v7"というsrcのないプロジェクトが勝手に作成されます。過去に作成したAndroidアプリを再実行するのには特に必要ありませんが、今回から新規に作成したAndroidプロジェクトでは環境設定でここにある"appcompat_v7.jar"というファイルを参照しているようで、自分が作成した覚えがないからといって削除してしまうとエラーになります。調べてみても、海外のQ&Aサイトで何件か質問がここ最近でていましが、特にこれはという回答が見つかりませんでした。googleのサイトを調べないとだめかな。

また、今回の更新でエラーが出るようになったというのもありましたが、Android SDK Manager/ExtraからAndroid Support Repository、Android Support Libraryをインストールすれば消えたという報告がありました。自分のエラーは他にも原因があり(.classpathの内容にも問題があった)、よくわかりませんが処置してみたら動くようになりました。でも結局、"appcompat_v7"が何者なのかはわからず、、、名前からするとARM v7関係なのかな。ということはintel系のアプリを作成すると別のものができる?→これ違いました、追記します

PS
昨年の夏にAction Barという新しいUIが実装されて、そのライブラリが"appcompat_v7.jar"らしいです。ついでにv7というのはSupport v7のことで、Android SDK Manager/ExtraからAndroid Support Libraryでインストールされるそうです。(だからこれインストールしとかないと実行時にエラーになったのか)だからってPackage Explorerの見えるところにわざわざおかなくてもいいのに。。。昨年の時は手動でプロジェクトを作成しないといけなかったようですが、それを自動的に作成するようにしたみたいです。

ところでこのSupportライブラリはAndroid2.3とか古いバージョンでもこの新しいUIを使えるようにしているということなので、ちょっと考えました。このUIを使う気がないなら、Android Support Libraryを外して、さらにAndroidプロジェクトを作成するときに最低バージョン(通常は2.3にしていますが)を4.0以上にしてやれば、この"appcompat_v7"という空のプロジェクトは作成されなくなります。(正確にはテーマも変えるべきなんですが。昔は"Theme.Ligt"とか"Theme.Black"だったのが、ActionBarという名称が今は追加されてくるはずです。個人的にAndroid4.0以上の端末しか持ってなければこの方がきれいなんですが、もうちょっと実装考えてくれないかな~Googleさん。)

更に調べてみましたが、このappcompatプロジェクトがライブラリプロジェクトとして作成したAndroidアプリのプロジェクトからはリンクする設定になっていました。
(だからPackage Explorer内にプロジェクトフォルダ作っちゃうんだ...)ただ困ったことに、今後新しいアプリのプロジェクトを作成する度に新しいもの(appcompat_v7_2, appcompat_v7_3等)と新しいライブラリプロジェクトを作成してくれちゃう状態になってました。まあ新しいappcompat_v7_*は削除して、新しいプロジェクトの上記リンク設定を最初に作成されたものに設定しなおしてしまえばいいんですが、ちょっとこれはたまりません。それにこのライブラリ自体が更新されたらソースの管理はどうなるんだろう?なんか悩ましい状況になっている気がします。