2017年12月25日月曜日

ConoHa Advent Calendar 25日目：美雲このはと象とあひる焼き


こんばんは、しまだです。トリを取ってしまいましたということで ConoHa アドベントカレンダーの25日目をお送りします。今回は ConoHa で Mastodon 動かしてますという話です(例年のような熱いネタではなくてすみません...orz)。

今年も後ろから美雲このは先生を見ていましたが、おおむねキャラ崩壊もなく、いつのまにか NHK にゲリラ出演していたり、更にいつのまにかアイドル活動も再開していたなど、座敷わらしにとっては大変有意義な年だったものと思います。

しかし、ことOSS勢の僕にとっては波乱の１年でした。
僕にとっても言論の根幹にあるマイクロブログなのですが、Post Truth (※) 化する Twitter の元、ノイズが多く流れ、対応クライアントやサードパーティが減っていき、さらには多くの開発者の口が塞がれ(凍らされ)ていきました。その一方、オルタナイティブとして 4 月に Mastodon が流行り始めてから、そちらへの移動が目に見えて増えてきました。技術者てのは根は町工場とかによくいらっしゃる職人のような存在だと考えており、普段口汚くても、いい仕事をする人が多いはずです。なのですが、そのような人たちが巻き込まれだしているのはどうなの、と思いはじめていたので丁度よかったのかもしれません。

(※) 「客観的な事実が重視されず、感情的な訴えが政治的に影響を与える状況」だそうです

ということで今年は、自分の言論は自分で守る、という意識の高い人から、身内話する場所欲しいよねといったカジュアルな用途まで、Mastodon, GNU Social を始めとするマイクロブログサーバがだいぶ幅を利かすようになり、4月から国内でも多くのインスタンスが走るようになりました。他社のVPSで立ててるケース🌸がやっぱり多いんじゃないの？ということもよく聞きますが、根っから美雲このは先生にお世話になっている僕等にとっては ConoHa で作る選択肢がファーストになるわけです。

実は去年までは定期的に現行の ConoHa をずっと稼働していたことがなかったのですが（すみません....）、今年の僕は、それに呼応してか、 Mastodon インスタンス稼働のために ConoHa VPS の定期稼働をはじめました。それが、いなこんこと inari.opencocon.org でして、これを立てたのは Mastodon が流行りだした 4 月ぐらいだったと思います。
僕のプロジェクトである opencocon について語れる、(Twitterでよくあるような)クソリプとかFF外指摘とかの少ない議論用チャットサーバが欲しいなぁと思って、Mattermost とかの設置を検討していたのですが、丁度 Mastodon が流行りだしたので、このために（記事冒頭の） ConoHa カードをすぐに買い、飛びついてしまった次第です。

ユーザ100人、普段の人口2人ぐらいと、大変細々とした Mastodon インスタンスですが、稼働しはじめてから、バージョンアップするとき以外は一度も落ちることなく安定して稼働を続けています。


MastodonのWebインターフェイスはこんな画面です。TweetDeckのような画面であり、そこそこ以上のスペックのマシンであれば、特にMastodon専用クライアントを使わなくても不自由なく使えるのが便利です。

（あ、ちなみにユーザ登録空けてますのでご自由にアカウント取って喋ってもらってかまわないです。開発メモを長々と書いていることが多いですが話題はフィルタしていません。）

5月にこのことをまとめた発表を東海道らぐで行ったことがあります。雑ですがスライドを貼っておきます。(スライド7〜8枚目あたりにその経緯があります)



ConoHa での Mastodon テンプレートができるはるか前に VM を作成していたのでテンプレートがどう便利かはわからずじまいな現状ですが、それでも普通にUbuntu等のVMを起動して、公式の Docker ベースのインストールマニュアルを通すだけで動くのは有り難いところです。

当初ストレージが間に合うか大変心配であったのですが、個人インスタンスに毛が生えた程度ではあまり容量を消費しないようで、現状それほどデータがなく標準の 50GB のストレージで間に合っています。おそらく文字中心のインスタンスなら基本スペックだけでも何年かは普通にいけるのでしょうが、いずれ増えてきたら画像をオブジェクトストレージ側に置こうと考えています。あと、回線は言うまでもなく安定しているのは流石といったところでしょうか。

Mastodon で実装が案外適当なのが通知メールまわりの実装であり、これも標準では Mailgun を使う設定になっているのですが、まともにメール送れていない！という声は前から多いので、これもこのはのメールサーバに向けるように直そうかなと考えているこの頃です。メール送信ぐらいなら理論上は自前でもできるはずなのですが、趣味でやるにはあまりにも敷居が高くなってしまっている気もしなくもないのですよね。

今年は相当多忙であったため、何かしら ConoHa を用いたhackは断念しました、すみません。しかもどっちかというとめっちゃ Mastodon の話になっていました。しかし、そのぐらい今年は、普通に情報発信できることの大切さを感じました。更に、そのために普通に ConoHa でサーバ立てて使うとは思いもよらなかったなぁというのが正直な感想です。これからも美雲このは先生に怒られない程度に（Twitterよりは寛容であると信じていますよ？）情報発信を続けていければと思います。


最後に、ConoHa のターゲットであるシステム開発者・運用者宛にはまだそれほど影響はないのかもしれませんが、コアな客層はもはや Twitter ではリーチできないケースが出てきたように感じます。来年の美雲このは先生にひとつ要望があるとするなら、Twitter と Facebook のほか、Mastodon 等の OStatus / ActivityPub プロトコルを用いた宣伝をそろそろ検討いただければ幸いです。最初はTwitterのミラーでも構いませんので...。
(単に僕が美雲このは先生を確認するためだけに Twitter 開くのがめんどいってのもあったりはします。)

というわけで、ConoHa アドベントカレンダーは閉幕ちゅうことで美雲このは先生にマイクをお返ししようと思います。よいお年を。

投稿者 時刻: 0 件のコメント:

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 アドベントは閉幕...でしょうかね(〆たのは初めて)。皆様良いお年を。
投稿者 時刻: 0 件のコメント:

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 が将来不要になる日は来るかもしれません。
投稿者 時刻: 0 件のコメント:

2015年12月19日土曜日

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

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

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

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

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

実はここまでで結構へとへとだったりしますが、出すだけでは何もできません。幸い３台とも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 アドベントはあひる焼きさんです。
投稿者 時刻: 0 件のコメント:

2015年12月10日木曜日

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

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


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


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


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

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








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

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

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

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


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


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

動作例：opencoconが動くLibretto 50。（詳しくはこの辺をどうぞ）

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

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

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

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

 本来は開発と公開マシンを分割した方が良いのですが、現在はひとつの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程度の消費でしょう) 
  • １回計測です。本当はあかんけど、これ自体ネタやし手抜きさせてください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を使うのは選択肢としてありだと思うのです。

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

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


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


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


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

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

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



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

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

投稿者 時刻: 0 件のコメント:

2015年12月1日火曜日

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





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

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

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



僕とあひるとあひる焼き

僕があひるさんを知ったのはだいたい２年前ぐらいでしょうか。あひるさんが、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のあっきぃさんだと思いますが、勿論間でもエントリーお待ちしております。
投稿者 時刻: 0 件のコメント:

2014年12月23日火曜日

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

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

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

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

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

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



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

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


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


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

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

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

 牛めしの具

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

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


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

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



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



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

牛めしバーガー

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

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

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

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

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

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

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

できあがり。

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

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

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

牛めしピラフ

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



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



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

まとめ

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

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

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

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



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

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

投稿者 時刻: 0 件のコメント:
登録: 投稿 (Atom)