2016年12月25日日曜日

ConoHa Advent Calendar 25日目:ConoHa APIで、このはシンクライアントを試作する

 
どうも、島田です。今回は ConoHa アドベントカレンダーの最終日ということで適当に書きます。
思いっきりトリを取ってしまった訳ですが、多忙な時期をずらしたいねーということで適当にこの辺に入れた次第です。結局思惑外れてめっちゃ忙しいのですが。orz

今年のConoHa

今年はざっと振り返ると、機能追加というよりはサービス拡充が充実した一年だったかなと思います。

そんな中でも技術的にはまた次の展開が見えてきたような気がしますね。ブロックチェーンなんかも気になります(まだちゃんと調べていませんが)。ただ、ベースで使っている OpenStack のバージョンも結構上がっていますし、そろそろ次を期待....はできるのかな?というのはちょっと思っています。
ConoHaでたまに聞く欠点であるSSD容量の少なさと、VMプランの少なさを何らかの形でカバーできればいいのですが...。

ちなみに、今年の座敷わらしこと美雲このは先生とのやりとりはこんな感じでした。相変わらずのやりたい放題ですんません。



そんなこんなで相変わらずお世話になっています。ということで今年もちょっと ConoHa で遊んでみました的レポートをお届けします。


 本題:APIを使ってConoHaのVMをシンクライアント的に使ってみる(試作)

さて本題ですが、VPSの邪道な使い方としてLinux GUI環境を使うというのがあります。基本的にはあまりお勧めできないような使い方にも見えなくはないのですが、最近のConoHaはSSDやし回線もそこそこ強いので、それっぽいこともできなくはないでしょう。

その手段として、あらかじめGUI環境とVNC / RDPサーバをインストールして、起動しっぱなしにしておくといった使い方はよく見かけます。

 しかし、ConoHa API でVMの生成とか起動削除ができるのならば、VM立てっぱなしの必要の必要ないんじゃないか?とふと思いました。必要になったときにスクリプトを走らせれば、シンクライアント用のVMがスポーンしてすぐ使える(ついでに使った時間分だけ課金される)ってなれば面白いと思いませんか? (思う人はほぼ居ないと思いますが...)

ということでちょっと試作してみたいと思います。

 VMイメージの作成 : Xubuntu デスクトップ環境とxrdp

今回は時間がないので、あらかじめ GUI 環境と xrdp を仕込んで固めたイメージを作ることにします。普通にConoHa上で Ubuntu 16.04 (64bit) テンプレートを選択してVMを作成し、まずは一般ユーザを作成してパスワードをつけます。
# useradd -m -G adm,sudo shimada
# passwd shimada
次に以下のコマンドで、Xubuntu 同等のデスクトップ環境を一気にインストールしてしまいます。少し時間がかかります。
# apt-get update
# apt-get dist-upgrade
# apt-get install lightdm xubuntu-desktop gksu leafpad synaptic
# apt-get clean
これで再起動します。
# reboot
ここまで行って ConoHa コントロールパネル上のコンソールを見ると、Xubuntuのログイン画面が出ているのが判ると思います。

ConoHa上のコンソールに現れた Xubuntu ログイン画面
ログイン後の画面
そのままFirefoxを実行すればブラウジングできる。但し描画やマウス移動は遅い。

この時点でもログインして、Webブラウザとかで遊べてしまいます。しかし、これは Web ブラウザ上で、かつ NoVNC 上なので、シンクライアントするには速度も使い勝手も微妙だと思います。


次に、このVMに xrdp (RDPサーバ)をインストールします。この部分は、日本 xrdp ユーザ会さんの情報とかを基に、X11RDP-O-Matic インストーラを使用して導入します。

X11RDP-o-Matic を使って xrdp を導入します。
(Ubuntu 16.04なので、上記サイトの方法から若干アレンジしています。またbuildを行う
のでしばらく時間がかかります。)
$ git clone -b master https://github.com/scarygliders/X11RDP-o-Matic.git
$ cd X11RDP-o-Matic
$ sudo ./X11rdp-o-matic.sh --justdoit --branch v0.8 --cleanup
上記のコマンドが全自動でインストール後、若干の修正が必要です。
まず、systemd まわりが RedHat 系ぽい指定方法になっているので直す必要があります。

修正するファイルは以下のふたつの
/lib/systemd/system/xrdp-sesman.service
/lib/systemd/system/xrdp.service

以下の行を修正しましょう。
EnvironmentFile=/etc/sysconfig/xrdp



EnvironmentFile=/etc/default/xrdp
あとは変更を反映します。
$ sudo systemctl daemon-reload
RSAキーを生成しましょう。
$ cd /etc/xrdp/
$ sudo xrdp-keygen xrdp
xrdpを有効にして起動します。これでRDPで繋がるようになるはずです。一度繋いでみてログインまで確認するとよいかと思います。

$ sudo systemctl enable xrdp
$ sudo systemctl enable xrdp-sesman
$ sudo systemctl restart xrdp
$ sudo systemctl restart xrdp-sesman

ここまで環境構築を終えたら、VMを終了し、ConoHaのコントロールパネル「イメージの保存」を選択します。しばらくするとイメージリストに項目が現れるので、それを確認したら現在のVMを削除してしまいましょう。これで準備完了です。

ConoHa APIで全自動VM作成 + RDP接続をする(試作)

あとは ConoHa API との通信には Example でおなじみ curl コマンドと、json パーサである jq を使用し、下手なシェル芸を駆使して、VMの作成 -> 起動 -> IPアドレスを拾って FreeRDP (RDPクライアント) に接続させるといったことを全自動で行います。

...といっても、この辺のscriptはここに貼り付けると長いので、Gistに貼っておきました。これをダウンロードし、冒頭にある ConoHa APIのユーザ名、パスワード、テナントID、保存したイメージ名、起動するVMのプラン(フレーバー) 等を適当に設定して実行するといけると思います....が、突貫で作ったためエラーチェックをすっとばしている等、色々危ないスクリプトですので実行は凄く推奨できません。座敷わらしに侵入されても責任は負えません、参考程度にどうぞ。

こちらで実行してみると、約10分ほどで FreeRDPが起動し、さっきと同じように直ぐ Xubuntu デスクトップ環境が楽しめるようになります。RDPプロトコルですので、NoVNC と異なり、反応はそこそこ速いのが実感いただけるものと思います。

急ごしらえで書いたスクリプトを実行したところの画面。右のshellに、非表示にし忘れた curl コマンドのプログレス表示の一端が見える。

ログイン後 Firefox を実行したときの画面。よく見ると、グラテーションのようなものがかかったような減色後が見られることから、RDPの方で回線帯域に応じた最適化をかけていることが判る。

なお、VMの削除までは実装していないため、起動して遊んだらConoHa コントロールパネルからVMを削除しましょう


考察

 以上はあくまで駆け足での試作であり、実際に実用に使うには色々とハードルがあると思います。特にRDPポート(Port 3389)がそのまま開いているのは怖いので、本当はポートを閉じておい
て、SSH ポートフォワーディングなりVPNなりと併用した方がベターでしょう。

また、シンクライアントは回線帯域を使いまくるということも気をつけるべきでしょう。RDPサーバかクライアントの設定で色数を落としたり、解像度を下げたり圧縮率を上げるなどの対策を一通り取ることをおすすめします。

後はVMのイメージが少々大きいというのも解決すべき問題だと思います。今回試作したイメージは15GBありました。これを毎回展開ってなると正直しんどいので、X11RDP-o-Matic時の中間ファイルを削除するなどして、もっともっと削る必要があるでしょう。 後shutdown時にパスワードが聞かれる等、細かいチューニングも必要です。


と、課題だらけで座敷わらしに怒られそうではあるのですが、適当に書いたスクリプトで全自動で無から仮想シンクライアント環境が出来上がって、実際動くのは楽しいですね。手前味噌ですが僕自身は opencocon というシンクライアントLinuxディストリビューションを作ってるので、これを真面目に書けば、各種 VPN 同様にメニュー項目に入って必要事項を入力するか、設定ファイルに追記するだけで ConoHa上に VM ができて、シンクライアント環境がすぐできる、といったこともできるかもしれません。
 
後根本的な問題として、VPSでシンクライアントってどうなんって話はやはり否めません。しかしそれ専用のサービスは相変わらず高価であることが多いですので、諸々課題が解決さえできれば、選択肢のひとつとしてはありだと思ってはいます。





BTW:NGワードの意味

おっと、最後にもうひとつ。少し前にOSS関係者な方と、ConoHa ACのNGワードについて、もうその意味を知ってる人はもう多くないやろなーと話していたので、その意味について少しメモしておきます。

今でこそ、ConoHaとそのキャラクター的座敷わらしである美雲このは氏は純粋に清楚かわいいマーケティングをしているわけですが、初期からConoHaを使ってる人ならご存知の通り、昔のTwitterでのマーケティングはNGワードがよく似合う時期がありました。そんな頃のツイートを一部紹介しますとこんな感じです。



今はもう笑い話ですが、当時はこんなんじゃ技術的に優れて安価であっても、こんな宣伝じゃConoHa駄目なんとちゃうの、と批判する向きもありました。

ちなみに、そこらじゅうからツッコミを食らっていたのを逆手に取り、TechOYAJIなるイベントも開催していたことがあります。今から思えば、インフラ技術をご存知の方にConoHaを知ってもらうための手段としてのNGワードだったのかなとも思います。多分仕掛ける側でも色々ゴタゴタはあったかと思いますが...。

 そんな過去のモヤモヤがあるため、これからも清楚かわいい、かつ皆に遊んでもらえるサービスであり続けてもらうために、 このはがキャラ崩壊かな?という時には今でもNGワードを発動する用意があるわけです。ご理解いただければ幸いです。

さいごに

僕自身何年か仕事で OpenStack を触ってきたのですが、昔のバージョンはだいぶ不具合が多かったものの、ここ数年で(感覚としてはJuno辺りから..?)だいぶ安定してきたように思います。しかし、初期のConoHaはそれ以前のバージョンがベースだと考えると、多分最初の立ち上げは大変だっただろうなぁとなんとなく思いました。身を持ってOpenStackの大変さを感じた者として、ConoHaを支える技術屋の方に敬意を表します。

多分OpenStackってまだ発展途上で、今はまだまだできることの表面しか触ってないように思いますし、それに伴いConoHaも伸ばせるところはあるんじゃないかと思います。最初にも書きましたが、来年もおもろい展開を期待しています。



これで、ConoHa アドベントは閉幕...でしょうかね(〆たのは初めて)。皆様良いお年を。

2016年9月5日月曜日

OpenStack : お手軽にポートフォワーディングして、IPアドレスを有効活用する

訳あってこの頃OpenStackをちょくちょく触ることがあります。始めたばかりのときはIcehouseでしたので、結構不安定であり苦労しましたが、最近のLibertyとかMitakaは基本的な機能に目立った不具合もなく、なんとか使えるような感触になってきました。

それでも、実運用で現場に当ててみると、そのままではうまくいかない部分が少々あるため、Tips的に記事を出していければええのかなと思います。(ツッコミが怖いですが...)

とりあえず、ポートフォワーディングしたい

OpenStackのNeutronは通常、Floating IP等を用いて、インスタンスと外部ネットワークをグローバルIP等を用いてダイレクトに通信する仕組みを持っています。 実際の運用においてFloating IPをふんだんに使える環境であればこの仕組みは便利に機能するのですが、実際にはこうにはいかないケースが多いものと思います。中には、利用可能なグローバルIPはひとつだけ、という家庭のネット環境に近い実環境もあるかもしれません。

そんな場合、Neutron で router を作成してそこから通信する形になるのですが、そのままではインスタンスにWebサーバを立てたとしても、外部からそれにアクセスすることができません。 この点においては、現状のOpenStackでは外部->内部へのポートフォワーディングAPI等の仕組みがありません(後述)。

幸い、RDO等でインストールした普通(?)のNeutronでは、router でNAT的な処理を行う部分は、 Linux kernel の機能である iptables で行われていますので、そこにDNATルールを追加すればこの欠点を補うことができます。つまり、手動でポートフォワーディングをしてあげれば良い感じです。

この部分は通常の iptables では指定できず、namespace で区切られた部分のみとなりますので、例えばルールを追加するときは、例えば以下のようにコマンドを入れる必要があります。

※ 以下の例は、Neutronにrouterがひとつだけある場合を想定しています。2つ以上ある場合は、$(/sbin/ip netns|/usr/bin/grep qrouter) の部分を該当の qrouter 名に置き換えてください。

From : 外部ネットワーク (192.168.1.100:5001) -> 内部のインスタンス (192.168.50.11:22) とした

# ip netns exec $(/sbin/ip netns|/usr/bin/grep qrouter) iptables  -t nat -A PREROUTING -p tcp -m tcp --dport 5001 -d 192.168.1.100/32 -j DNAT --to 192.168.50.11:22

これだけで外部からの通信がポートフォワーディングされますが、この設定は reboot 等で消えてしまうため、保存する仕組みを作る必要があります。
手動では以下のコマンドで保存することができます。

# ip netns exec $(/sbin/ip netns|/usr/bin/grep qrouter) iptables-save > /etc/iptables-namespace

同じように復元するには以下のコマンドで行います。

# /sbin/ip netns exec $(/sbin/ip netns|/usr/bin/grep qrouter) /sbin/iptables-restore < /etc/iptables-namespace

ポートフォワーディングを起動時に自動適用したい

次に、このスクリプトをサーバ自体の起動時に自動的に反映されるようにします。なぜこれが必要なのかといいますと、何らかの原因で再起動が必要になった際に、設定を失ったり、手動での反映を失念するのを防ぎたいからです。

しかし、ただ systemd に仕掛ければよい訳ではありません。qrouter-* ネームスペースが生成されるのは起動シーケンスが見た目終了してしばらく後と大変遅く、仕掛けづらい状況です。いろいろ試行錯誤しましたが、Neutronの起動が完了したタイミングでもうまくいきません。 このため、今のところ systemd ファイルを以下のように書いてみます(抜粋です)。

( /usr/lib/systemd/system/openstack-namespace-iptables.service )


[Unit]

Description=Setup iptables on Linux namespace

DefaultDependencies=false

After=neutron-server.service



[Service]

Type=oneshot

ExecStart=/usr/local/bin/openstack-namespace-iptables restore

ExecStop=/usr/local/bin/openstack-namespace-iptables backup

TimeoutSec=60

RemainAfterExit=yes



[Install]

RequiredBy=multi-user.target



( /usr/local/bin/openstack-namespace-iptables )

#!/bin/sh



logfile="/var/log/iptables-namespace.log"

iptables_file="/etc/iptables-namespace"

iptables_backup_file="$iptables_file"



# Wait for standup namespaces (because always delay about 1 min).

while :

do

  namespace="$(/sbin/ip netns|/usr/bin/grep qrouter)"

  if [ "$namespace" ];

  then

    break;

  fi

  sleep 2

done

… (以下省略)

 本当は、このスクリプトはもっと改良の余地があると思います。qrouter-* namespace が見えるようになってから、という点を [Unit] の After= 以下に書ければいいのですが、その辺どうやるべきか思いつかず、こんな表現になってしまっています。 それでも、手元の環境ではある程度の確率(100%ではないのですが…)で自動的に namespace 内の iptables に反映できるようになるかと思います。

これらのScriptはダウンロードできるようにしましたので、参考にしていただければと思います。
CentOS 7 で実際に動かしています。

根本策?

根本的には、FWaaS側にポートフォワーディングの機能があり、APIで操作できればこのような手動設定を行う必要がなく、またHA構成であったり、バックエンドが iptables ではなく MidoNet 等の場合でもスムーズな対応を期待できるのですが、残念ながら blueprint に複数の要望が 上がってる程度で、まだ搭載までは至っていないようです。

...とここまで書いたところで再度調べてみたのですが、作業を行っていると思われるlaunchpadでは、最近少しづつではありますが実装作業が行われている(らしい)状況ですので、この Tips が将来不要になる日は来るかもしれません。

2015年12月19日土曜日

Eject Advent Calendar 19日目:CDドライブに運をまかせてみる

どうも、島田です。
今回は久々のEJECTアドベントカレンダーということで書こうかと思います。

が、しかしネタ切れにも程があるこの頃、何やろうかと散々悩んでいました。一応買い出しには行ったのですが、なんというかどーしようで終わっていた感じでした。

というわけで、家の中を捜索して見つけたEJECT装置をなんとなく並べてみました。

 3台見つかりました。つまり3EJECT。

実はここまでで結構へとへとだったりしますが、出すだけでは何もできません。幸い3台ともUSBインターフェイスがついているので、これとUSBハブにつないでまとめます。更には、CDドライブの電源をタップにまとめます。

こうすることで、PCにつなげるインターフェイスは1本のUSBケーブルにまとまりますし、タップの抜き差しor電源スイッチでまとめてCDドライブのオンオフができます。実験環境のとっかかりはシンプルな方がよいでしょう。


では、次に手元のLinux端末でスクリプトを書いてみます。3台もあるので、何台増やしてもいいように、少しはインテリジェントに書きたいなーと思い、Shell script での配列の使い方を学びながら、こう書いてみました。

(fortune_eject.sh)

#!/bin/bash

# Linuxで認識されているCDドライブをすべて配列に入れる
drives=(`ls -1 /dev/sr*`)

#どれをEJECTするか決める(この場合はランダム)

num=` expr $RANDOM % ${#drives[*]} `

eject -T ${drives[$num]}



スクリプトを書いたら実行権限をつけましょう。

$ chmod +x fortune_eject.sh

num変数にて、どのドライブをウイーンさせるかというのを指定することができますが、ここではランダムにしてみました。するとどうなるかといいますと、3台あるCDドライブのどれかがEJECTするようになります。どれかは選べません。

あとはこれ繰り返し実行しましょう。以下のコマンドでさくっと永久ループできます。

$ while :; do ./fortune_eject.sh ; done

すると、延々と EJECT しては戻りを繰り返すようになります。

ちょっとランダムにしては偏ってないか気になる感じですね。

ここまでで気づいたのは、ドライブによってウイーンする時間が異なることと、特に下のドライブが、クローズ後にロードするような挙動をすることがある程度でしょうか。やはり均等で高品質なEJECTをするには、ドライブを揃えたほうがいいのでしょうか。

さて、ここまで揃えたところで、表題の通り運を任せてみましょうか。といってもよさげなAfter Eject ネタがないので、とりあえずCDドライブのところにぬいぐるみを並べ、fortuneしてみましょう。


気になる結果は...?



あひるが動きましたね。今夜のご飯はあひる焼きとしましょうか。


とこんな感じで、複数台でのEJECTは割と簡単にできますし、慣れればどんどん増やすことができます。USBハブを介してるので、このままRpiとかにつないでも安心です。

ただ欠点は配線が面倒なのがありますし、やはり12EJECTぐらい無いとインパクトがありませんね。
もっとハードオフで買い漁りたいものです。

今回は時間がなくネタができませんでしたが、次はベルをいろいろと買って、シーケンス的に何か鳴らすとかやってみたいものです。あとShell scriptでも非同期実行を極めて、よりスムーズなEJECTをしたいなぁというのも思いました。

ではでは、明日のEJECT アドベントはあひる焼きさんです

2015年12月10日木曜日

ConoHa Advent Calendar 10日目:やんちゃなConoHaで、ディストリビューション開発

本日はConoHaアドベントカレンダーということで、今回はVPSサービスのConoHa(以下このは)を数年間使ってきて感じたことと、僕が主に進めているOSSプロジェクトである opencocon でこのはを使っている事例とかをお伝えできればと思います。


このはを振り返って:僕が見た、やんちゃで楽しいVPS


僕がこのはを知ったのは2013年頃でしょうか。そこそこリーズナブルで、自由にOS突っこめて、グローバルIP(v4, v6)が使えてということで、普通に遊べるVPSができたなーすげーという感じであったでのですが、何といってもサービスのトップページからして萌えており、デカイこのは先生がどーんと出てくるのが初期のこのはでした。
実は同時期に仕事でVPSを探してたことがあったのですが、「使えそうなのに上司に勧められない」という、すごく独特なポジションを持っていたことを思い出します。一応、なんでそうなんったん?とブースでお伺いしたことがあるのですが、「我々はこれでいきます!と決めたので・・・」という、ある意味正々堂々とした答えを頂いた覚えがあります。


あれから3年、現在は2代目このはになり、全面的にSSDを採用したりOpenStack APIを部分的に使えるようになったり、クレカ無くてもチャージできるようになった等の磨きがかかる一方、以前の萌えトップページは後ろに隠れました。より多くの人に使ってもらうために、色々と成長(意味深)したのでしょう。

ただ、初期からの萌える勢いが残る美雲このはTwitterアカウント(@MikumoConoHa)とかもありまして、これがまた昔からフリーダムでした。時期によって異なる口調、時々繰り出る若い人には絶対判らないネタ、「あーこれ中の人疲れた勢いで書いてるんやろなー」と思う場面、挙句の果てにキャラ崩壊寸前....。今はだいぶキャラ崩壊は無くなってきたようには見えるのですが、やってることが自由なのは相変わらずのようです。
僕がメモしてある、このはの過去の絡みを以下に少し挙げてみますと、こんな感じでしょうか。








(補足:あひる焼きについては、こちらで解説しています)

もうなんていうか、お互いやりたい放題な感じが...(すんません)。

恐らくこういうプロモーションに賛否は色々あるんでしょうし、たまに、おいやめろと突っ込みたくなるような場面はあるのですが、思えばこういった面もこのはがやんちゃな所以なのかなとも思っていますし、真面目にVPSサービス作ってるだけじゃおもろないんやって言わんとばかりの、提供側の熱意を感じる訳です。やっぱり遊び心あっての本気のWebサービスですよね、多分。

そんなこんなでこのはの雑感を話したところで、私がやっているこのはの活用方法を簡単に紹介したいかと思います。


このはとここん:Linuxディストリ開発にVPS使っています


さて話が変わりますが、私が中心で開発しているOSSにopencocon(おーぷんここん)というのがあります。これは、旧型コンピュータをシンクライアントにする、専用型Linuxディストリビューションです。

動作例:opencoconが動くLibretto 50。(詳しくはこの辺をどうぞ)

 詳細はサイトの方を見て頂くとしまして、これは、今まで誰もが一度は考えたけどうまくは実現するのが難しかった、旧型コンピュータでシンクライアントを簡単にしたい!というアイデアを具体化したくて、僕を中心に何年か開発を続けているものです。

このプロジェクトは旧型コンピュータこそ沢山あるのですが、いかんせん肝心の資金に乏しく、僕自身経済的に苦しい時期に立ち上げたプロジェクトでした。当時は公開するための自宅サーバを引ける回線すらなかった程だったのです。そんな中、当時のお名前.com VPSさんのコミュニティ支援制度により、VPSをお借りできたおかげで、なんとかプロジェクトを軌道に乗せることがができました。その流れで、このはの開始時より引き続きコミュニティ支援を頂いており(※)、その間に10以上のリリースをVPSで作っています。
 (※現在新規のコミュニティ支援はしてないそうです。ただ、面白い若手を呼び込むためにも、予算がつきましたらまたお願いできればと思っています。)

その際、折角お借りしてるVPS(といっても1台ですが)やし有効に使わんとと思い、いろいろ試した結果、VPSの中で opencocon のビルドを行いつつ、一方でサイトで公開しても問題ないぐらいのスペックだということに気づきました。そこで、以下の図のような開発体制を取ることにしました。

開発フロー(って言わないと思いますが)図。1台2役です。

 本来は開発と公開マシンを分割した方が良いのですが、現在はひとつのVM内で権限などで線を引くことによりなんとかしています。セキュリティ的には色々と余地があるのでしょうけど、スタートアッププロジェクトとしてはそんなにボコボコVMは立てられません。まさに貧乏プロジェクトという感じでしょうか。 (いずれなんとかしたいものです...orz)
 
opencocon は各地でのブース出展を行い、それに向けてこまめにバージョンアップしながら制作を進めている訳ですが、直前までイメージを調整してその成果をCDに焼く ことがよくあります。ただ、荷物が大変重くてビルド用マシンまで持っていくことができないですし、電源プラグがない環境で半日移動しなければならないケースも多いので、手元でビルドとかはしんどいわけです。

そこで、適当なSSHコンソールに入れるマシンと回線を持参し、そこでSSH越しにこのはのVPSに入り、そこでコーディングとビルドを行い、手元に完成イメージ(ISO等)をダウンロードして動作テストとCD焼きを行う、といったクラウド開発のような手法を取っているのです。こうすることにより、高い(出展)機動力とアーリーリリースを両立(?)できるわけです。

とまぁ、こんな経緯がありまして、現在もopencoconのサイトの横に「Compiled on ConoHa」と表示させて頂いています。

opencocon.orgの右側にあります。これは純粋なリンクでありアフィリエイトではないです。


このはで、ここんを作るベンチマークをやってみた


opencoconのユニークな点のひとつは、組み込みLinuxフレームワーク(OpenEmbedded)ベースであるということです。これは軽量化にものすごく貢献するチョイスなのですが、その代わり opencocon を生成するには、そのすべてをクロスコンパイルする必要があります。ということで、このはが実際にその観点で使えそうなVPSなん?てのを軽くスピードテストしてみようかと思います。
手前味噌なopencoconのイメージを、新このは、旧このは、あとオンプレのマシンでビルドを行い、その速度を簡単に比較してみましょう。

現行の opencocon v9 フルビルドでは、どういうことか時々コンパイル中にコケたりCPUが100%になる等、いくつかの問題を抱えているため、完全に自動化することができない状況あり、計測に適していませんし、何より時間がかかりすぎます。ですので、最低限の初期起動用initrdイメージ(initramfs-crusoe-image)の生成だけを計測することにします。

 具体的には、opencocon v9のビルド方法を途中まで進め、以下のシェルスクリプトでビルドを走らせます。

(build.sh)

#!/bin/bash -
set -o nounset
source ./opencocon

startt=`date +%s`
bitbake initramfs-crusoe-image
endt=`date +%s`

echo "TIME : ` expr $endt - $startt `"




さて、比較のために用意したマシンが環境はこちらです。
  • その辺で拾った Core Duo ノート
    Core Duo T2300 1.7GHz, Memory 1GB, HDD, Debian 8 (これのみ32bit)
  • あひる焼き氏に寄贈頂いた Core i7 デスクトップ
    Core i7 2600K 3.6GHz, Memoy 12GB, HDD, Ubuntu 14.04
  • コミュニティ支援頂いている旧ConoHa
    Xeon E5-2670 [3CPU] 2.6GHz, Memory 2GB, HDD, Debian 7
  • この計測のためにチャリンチャリン(コインを入れる音)した新ConoHa
    Xeon E5-2660 v3 [3CPU] 2.6GHz, Memory 2GB, SSD, Debian 8

他の条件としては、
  • ビルドオプションは常に -j2 となっています。
  • bitbakeでは各パッケージのソースを各サイトからダウンロードするのですが、この辺りの速度は特に気にしていません(すみません)。ですので、インターネット回線状況によりビルド時間が多少左右されることに留意が必要です。
  • ディストリの違いによる動作速度の違いが考えられますが、それ自体はあまり大きくないような気もします。
  • このはは共用ですので、コンディションによって一定の速度が出るとは限りません。
  • このは以外の2台は、特にVMの中で動かしたとかではありませんので、その辺りも留意が必要です。
  • HDD/SSDの空きは十分あるものとします。(おそらくこのレベルでは10GB程度の消費でしょう) 
  • 1回計測です。本当はあかんけど、これ自体ネタやし手抜きさせてくださいorz

こんな感じにビルドを廻していました。


というわけで、気になる結果はこちら。

  •  Core Duoノート
    13377秒 →約223分
  • Core i7 デスクトップ
    3749秒 → 約63分
  • 旧ConoHa
    7261秒 → 約121分
  • 新ConoHa
    5091秒 → 約85分

こんな結果になりました。

 考察ですが、どうもこの手のビルド処理はCPUの速さが最もモノを言うようであり、 CPUのHz数が高い i7 デスクトップがトップをマークしてしまいました。その次に、新このは、旧このは、Core Duoと続きました。

この結果から考えると、じゃあ高速なCPUの自作マシン組んでビルドを行えばいいんじゃない?とお考えの方も多いかと思います。そう言っちゃえばそうなのですが、これは物理マシンなので勿論動作音は大きいですし、さらに言うと家の回線はADSLなので、イメージがさくっとできても、直ぐにアップロードできる、というわけにはいきません。

それに対し、新このはで、計測のために500円をチャージし、4時間ぐらい動かしまして、引かれてるのがだいたい72円ぐらいでしょうか(ジュースよりも安いですね...)。もちろんデータセンターの中なので雷とか故障とか停電を気にする必要がなく、ダウンロード・アップロードともに高速でしょう。これを考えると、速度差を考慮したとしても、ビルドのためにVPSを使うのは選択肢としてありだと思うのです。

旧このはと新このはでは35分ほどの差がついているのも見どころですね。CPUは概ね似たような感じだと思うので、SSDとHDDの差が出た感じでしょうか。

今回は全体的に控えめなパラメータだったので、まだまだチューニングの余地はあると思います。


ちなみに、これまでの運用でのコンパイル時の負荷ですが、例えば3CPUプランの場合、 -j2 までであれば同時に動くWebサーバなどにあまり迷惑をかけずビルドできるかなという感じです。 それでも、opencoconのフルビルドは旧このはで6〜8時間ほどかかってしまう訳ですが・・・。


おわりに:組み込み開発でこのはを使うというアイデア


一般的にLinuxディストリビューションですとか、組み込みLinuxやAndoroidのROMは、手元の端末とかサーバでビルドするかと思います。その方がデバッグとかしやすいですし、何よりも手元で動くという安心感もあるかと思います。

では、その環境をこのはに移して使うことのメリットは何かといいますと、やはりデータセンター内にあるということと、迅速な共同開発、あと高速なダウンロードができるということでしょうか。最初からXeon、SSDといったリソースが備わった、そこそこ高速な環境が直ぐに用意できる、このはの中で開発とビルドを行うことは、ある種メリットがある使い方ですし、その上にJenkinsやBuildBotみたいなツールを乗せて自動化する使い方もありだと思います。

 ただ、このはならではの最大の欠点はといえばやはりディスク容量でしょうか。大量の中間ファイルやソースコードをさばくのには工夫が必要でしょう。その点では、初日に話のあったSwiftFSの検討も要るかもなーと思っています。このは的には今更HDDって訳にもいかないでしょうが、この辺よさげな落としどころが欲しいような気もしています。



というわけで、駆け足で活用事例をご紹介しました。何かお役にたてることがあれば幸いです。

最後に、長年opencoconプロジェクトを支援頂いてるこのはとGMOの皆様、ユーザの皆様にはいつも感謝していますとともに、来年こそはもっとおもろくて便利で、謎マシンに入れて楽しいディストリビューションを生み出せればと思います。ありがとうございました。

2015年12月1日火曜日

あひる焼きアドベントカレンダー : あひる焼きのはじまり





というわけで、あひる焼きアドベントカレンダーの1日目の記事です。

ここ1年、よくTwitterで「あひる焼き」が謎の流行?を見せていますが、どうしてこうなったんやという点をちょっとだけここでメモしておきます。

とその前に、前提知識がいろいろとあるので、先ずこの辺のスライドをご覧ください。



僕とあひるとあひる焼き

僕があひるさんを知ったのはだいたい2年前ぐらいでしょうか。あひるさんが、WordPressとか東海道らぐとかEJECTコマンドユーザ会に遊びに来て、LTデビューしたぐらいの時期だったと思います。色々なコミュニティに飛び込むべく探りを入れていたり、実際に参加していた時期でした。その時はあんまり面識はなかったのですが、既に行動が学生にしてはぶっとんでおり、ておくれていた感じであり、その時早くもTwitter上でいろんな人にいじられ愛されるキャラでした。



その流れで、その年の7月ぐらいから、僕とほか数名が、何故か突然あひるさんをTL上で調理するようになりました。名前があひるなので仕方ないね。






この頃はOSC名古屋やKernel/VM北陸がありましたし、ベイクドGPUで有名なすしさんの影響があったと考えられますが、今となっちゃ何が直接の原因かはよく判りません。恐らくは何かの成り行きでしょう。

多分、最初は蒸したりしてたと思うのですが、その中で放たれた世界で最初(らしい)の「あひる焼き」がこちらです。というか僕かよ。


有名な「あひる焼き」のフレーズは、もう少し経ってから確立することになります。見たところ、8~10月にかけて、東海道らぐとかmikutterユーザとかを中心にじわじわと広がっていった感じでしょうか。


あひるさんが危機感...というよりは、煽り返すのが大変になってきたのをなんとかすべく、mikutter の ahiru_yakuna プラグインを作った訳です。稼働開始の時期は11/24頃であり、最初は「ヒッヒッヒッ」しかリプライを返さなかったそうですが、後に色々なバリエーションができて、現在に至ります。
初期のリプライはこんな感じであり、まだ調整中の雰囲気を感じさせます。


その後の経緯....は、先のスライドにまとめられている通りだと思います。僕が聞いた話では、ahiru_yakuna プラグインが稼働したことにより、あひるさん自身の負担が下がり、かつ知名度が上がるという謎の効果がもたらされたそうです。

結局あひる焼きって何だったのか

よく判りませんって言えばそれまでなのですが、あひるさんの代名詞になるべくしてなったのかなという感じがします。有望なエンジニアであるとともに、ユーモアセンスを持ってOSS業界に飛び込むと、しばしばこういうよく判らない現象になるのかなぁと思っています。

同時に、うっ憤のたまりやすいエンジニアと、近年荒れに荒れるTwitterに疲れてる人も多い中、判りやすい気分転換(?)ができるbotができたのかなと僕は思っていますが、あひるさん本人はそんなこと考える由も無いでしょう。

あひる焼きは、東海道らぐでのキーワードになるほどになっていますし、それが縁でお会いした方も何人かいます。人生どうなるかわからんですね。

あひるさん本人とあひる焼き勢の皆さんに謎の感謝です。謎の、ですが。




というわけで、あひる焼きアドベントカレンダーはまったりと続くと思います。次は12/6のあっきぃさんだと思いますが、勿論間でもエントリーお待ちしております。

2014年12月23日火曜日

松屋 Advent Calendar 23日目:知られざる松屋冷凍食品の世界

こんにちは、島田です。松屋アドベントカレンダー2回目の登場です。数々の松屋ガチ勢を差し置いてええのかこれ、という感じで凄く恐縮なのですが進めます(ほんますんません...)。

青春の松屋:孤独と薄い本と牛めし

そろそろクリスマスですね。こんなときにこんなの読んでるのは恐らく非リア充でしょうから、昔話をお届けしましょうか。

私自身、2000年代中盤は関東に居ました。でもって、その頃のホームグラウンドは間違いなく秋葉原でした。でじこ看板の向かい側と高架橋をはさんだ向かいには松屋(秋葉原中央通り店)がある....10年ぐらいずっと変わらない光景ですね。

はす向かいにある、でじこ看板ことタカラダ無線ビル。



関東時代はまだ吉野家勢でした。しかしながら、秋葉原駅からは徒歩30秒ぐらいの差で松屋の方が近いためよく通っていました。
休日の夜遅くに繰り出すと、松屋以外に北千住でラーメンか蕎麦ぐらいしか選択肢がなかったというのもあります。ついでにいうと東武沿線の最寄り駅は食事できるところがないというのもありました。

あの頃は本当に孤独な学生でしたが、その後OSS業界にもぐりこみ、いつのまにかフロントランナーになっていました。今は大阪、名古屋と渡ったため今は滅多に秋葉原には行かなくなったものの、今でもあの松屋に入ると、薄い本とか機材を買ってしまいお金がないまま、寂しく牛めしを食べる、昔の自分を横で見るような錯覚をしみじみと覚えるのです。


思い出は意外なところにあるものだな、とここまで書いて思いました。


それでは、しんみりしたところで今回も何か食べましょうか。

 知られざる松屋冷凍食品を食す

さて、松屋では、細々とですが冷凍食品も販売しています(松屋では冷凍個食パックと言うらしいです)。一部の店舗の券売機に、「牛めしの具」などのボタンが入っていることもあり、その場合はその場で購入することができます。あまりこれを試す方は居ないかと思いますが、これはこれで店舗の味とはちょっと違った楽しみ方ができますし、遠方や多忙でなかなか #matsuyanow が出来ない時でも安心して #matsuyanow できます。
今回はその中からいくつかご紹介しましょう。

 牛めしの具

まずはスタンダードな牛めしの具から。これは説明不要の、ご飯とかに乗せるタイプの具というか肉です。

以前、AmazonのWishlistにて友人から頂きました。


では調理してみましょう。

鍋のお湯で温めてもよいのですが、電子レンジだとなんとそのまま袋を開けずに温めることができます。ただし、「この面を上」の表示をよくチェックしましょう。4分(500W)でOKです。



あとは、ご飯にかけてお好みのトッピングをして楽しんで食べましょう。島田スペシャルにするもよし、ポン酢どばどばするもよし、デスソースかけるもよし。



もっともスタンダードですし、店舗にあれば比較的持ち帰りに買いやすい部類だと思います。冷凍庫におひとついかがでしょうか。

牛めしバーガー

お次は牛めしバーガーです。これは現在店舗にはないようですが、一部店舗で販売していたもので、今はオンラインショップでのみ入手できます。

冷凍食品のパックとしての販売が基本ですが、店舗によってはその場ですぐに食べられる所もあったようです。

 丁度、以前貰った牛めしバーガーが冷凍庫に入っていたので、この機会に食べてみました。

一部にはおなじみ?牛めしバーガー。

まず、袋を開けると内袋が2つ出てきます。つまり2個入りです。

内袋の端を少し破りましょう。
 説明によると、内袋を皿に移し、皿に内袋の端を2cmほど開封してください、とあります。こうしないと蒸気が逃げずに危ないことになりますので、必ず開けましょう。

あとはレンジで4分(2つまとめて、600W)温めると・・・。

できあがり。

こんな感じにできました。肝心の味ですが、少し甘く(どっちかというとすきやき風味?)、やわらかめの牛めしとご飯がマッチしてなかなかいけます。モスの焼肉ライスバーガーに比べてもやさしめの味かなと思います。

サンドイッチスタイルですね。

そして、ライスバーガーなので袋を持ったまま食べることもできます。内袋は内側が滑りにくく、また肉汁が垂れにくく、さらに外側は汁などがつきにくい構造なので、片手が忙しいときや出先でも安心して食べることができます。

牛めしピラフ

最後に牛めしピラフの話を掘り返してみます。ここまで聞くと牛めしピラフは馴染みない、珍しい!という方も多いんじゃないでしょうか。それもそのはず、店舗でのメニューであまり出ていないでであろうチーズ系、さらにはピラフなのです。
これも今は販売されていませんので、2月ごろに取材したときのものです。これも偶然取り扱い店舗で見つけたので、とりあえず買ってみました。



作り方は簡単、風を開けて中のピラフをどさっと皿に盛って、ラップをかけてレンジで3分半(500W)かけるだけです。



当時の感想では一ひねり足らんな、という感じでしたが、今やってみるなら2袋開けた上で、温めたあとにレタスやミニトマトとかと一緒に盛るとシャレオツでなかなかいいんじゃないかな、と思っています。はい。

まとめ

ここでは紹介していませんが、他にもカレーや豚めしの具があります。どれも店舗のメニューより味が柔らかいので、松屋ガチ勢のみならず、滅多に外食せぇへん、肉っぽすぎる店舗牛めしはちょっと...という方にも丁度よいかなと思います。

ただ、残念な点は、松屋店舗というよりはスーパーとかで入手したい一品といえるところでしょうか。普通フリーザーバッグ持って松屋行く人居ませんよね・・・。
あとあまり安価ではないというのも挙げられると思いますが、それは人それぞれだと思いますのでなんともいえないところです。

参考までに、上記で紹介した個食パックは以下のサイト等で取り扱いがあるそうです。
※以下のリンクは無保証です。買う際は色々と確認した上ということでお願いしますね。
※アフェリエイトリンクではありません。押しても僕に収入などは入りません。

牛めしピラフ以外のすべて --- 松屋オンラインショップ
牛めしの具 --- Amazon 楽天
牛めしバーガー --- Amazon 楽天
牛めしピラフ --- 楽天



ということで、僕の方からはここまでということで皆様メリーマツヤナウ

明日からは皆さんお待ちかね、松屋を知り尽くした神が登場します。明日は松屋仮面V3ことおかのさん、あさっては松屋仮面のご本尊ことおしえ先生です。松屋ACのクライマックスを引き続きお楽しみくださいませ。

2014年12月16日火曜日

松屋 Advent Calendar 16日目:島田スペシャルってなんぞや

こんにちは、島田と申します。
久々のアドベンドカレンダーですね。もう技術系で12月を書きたくないのですが、これならええやろうということで。

なんかここまでのアドベントカレンダーの中身を見ていると、松屋好きすぎる!てノリの記事が主な感じがしますので、最初はちょっと視点を変えて、今年の松屋を振り返ろうかと思います。

ことしの松屋を振り返って:プレミアム牛めしの憂鬱

今年の松屋といえば、2月の大雪による販売休止、プレミアム牛めし、トマトカレーガチ勢、トンテキ定食(TTT)の供給遅れなど、季節によりメニューがよく変わる松屋にして考えても山あり谷ありだったように思いますが、なんといってもプレミアム牛めしが話題をさらいました。

牛めし(あるいは牛丼)という食べ物は、昨今の日本では蕎麦やおにぎりなどとともに、セーフティーネット的な外食系の食べ物として認識されていることが多いのではないでしょうか。つまり、お金がなくてもこれなら食べられる、という安心感のある食べ物という位置づけに、松屋の牛めしも入っていると思います。

これは、趣味にお金つぎ込み過ぎて(以下略)という方から、本当に生活保護に頼っているという方まで、幅広い層がいるということを忘れてはならないでしょう。

なので、首都圏を中心にプレミアム牛めしに切り替わった際、価格に敏感な人を中心に非難の嵐が起きました。並290円→380円の大幅アップですのでそんな反応も無理はないでしょう。実際、僕が堀田で先行発売されたプレミアム牛めしを食べに行った際のツイートを見ても、謎リプツッコミの多くがそのような方々でした。




確かに肉がよく、昔の吉野家っぽい牛めしでよかったなーと思いましたし、そんな反応も多かったのですが、前の方がよかったという話もこれまた聞きました。ニューコークの如く、定番の味を変えるのは難しいに違いありません。

その後、全国でプレミアム牛めし化するんじゃないかという話もありましたが、現在おおむね首都圏でプレミアム牛めしの展開が止まっています。この松屋の方針は現在も非難や疑問を持つ人がいるんじゃないかなと思います(僕もそうです)が、恐らく松屋サイドでも、高級志向とセーフティーネット、あとは諸々のコスト上昇の間で揺れてるんじゃないかなと思う訳です。


このあたり、来年はどうなるでしょうか。個人的にはもう少し納得のいくプレミアム・非プレミアム牛めしの棲み分けになって欲しいなと願うばかりではあります...。


さて、お堅い話をしたところで、早速松屋に行くとしますか。

島田スペシャルってなんぞや

突然ですが、個人的な牛めしのこだわりは、牛肉が見えなくなるぐらいネギをかける派です。おろしネギもいいのですが、おろし無しでねぎなのです。そして、ポン酢をどばどばかけるのが好きです。これはもはや牛めしというより、ネギ丼にしか見えない強烈な見た目が印象的です。

これを、何かのパクリで島田スペシャル(しまだスペシャル)と勝手に言ってます。ただ、いつからそう言ってるかは明らかではなく、なんか去年ぐらいからそう言ってたらしいという感じです(適当)。Twitterは昔の履歴あさるのが面倒ですが、昔のおかのさんのツイートを借りると去年6月っぽい感じがしています。



で、何故こんなシンプルかつストレートな謎トッピングなのかといいますと。
島田スペシャルは、元々は讃岐うどんでやっていたのに由来します。丸亀製麺とかでは、カウンターでネギをかけ放題なのをいいことに、麺を覆うようにネギをかけて食べる訳です。


これがまたリーズナブルな貧乏料理っぽく、シャキシャキの野菜(といってもネギだけですが)が摂取できるので、個人的にイケるわけです。これを牛めしでやればどうやろう?とか思ったのが、島田スペシャルであります。なんとも単純です。


松屋で島田スペシャルな牛めしを食べる

では、実際に島田スペシャルを実践してみましょう。まずは当然ですが松屋に行き、適当な食券を買いましょう。

次に、食券を店員さんに渡し、それと同時に青ねぎ(60円)を注文しましょう。というのも、券売機にほとんどの場合は青ねぎが入ってないためです。また、ICカードとかも使えない(と思います、未確認ですが)ので小銭を店員さんに渡しましょう。ミニ牛めしなら1皿(60円)、並以上であれば2皿(120円)が適当だと思います。

すると、こんな感じで来ます。これが島田スペシャルの素です。

あとはネギを牛めしのうえにかけ、テーブルにあるポン酢をどばどばしましょう。これで島田スペシャルになりました。


以前おかのさんが実験したところによると、肉が見えなくなるぐらいまでになるには、単品ねぎを3皿注文しないといけないそうですが、僕としては2皿あればおおむね十分だと思っています。この辺はお財布や体と相談しつつ増減したほうがよいでしょう。


島田スペシャルの利点としては、なんといってもネギフリークにはたまらないシャキシャキとしたフルーティな食感の牛めしになることでしょうか。松屋のネギはそれほど辛くないですし、ネギとポン酢で味が締まりますので、牛めし自体も飽きない感じにぺろっと食べることができます。初音ミク好きな方にもお勧めです。

逆に欠点といえば、ネギを2皿以上注文すると店員さんに怪しまれること、ネギが苦手な方には地獄にしか見えないことでしょうか(苦手な方、すみません...orz)。あとネギの食べすぎは時に体にあかんので、ほどほどにしましょう。



いかがでしたでしょうか。是非お試しくださいとは言いづらいですが、こんなのもあります程度に笑っていただければ幸いです。
明日は、これまた新しい食べ方を提案されるのかなという感じのタイトルなjunjiruさんです。