Cloud Penguins

Flying penguins in the cloud.

第二種電気工事士

先日第二種電気工事士の実技試験を受けてきたんですが、9/1に発表があり無事合格してました。

f:id:jaco-m:20170902211324j:plain

実は去年も受けていて、筆記は簡単に突破したんですが実技はどこかをミスったと考えられ、不合格になっていました。 1年間は学科免除になるとのことなので、今年再挑戦した次第。

勉強や練習に費やした時間は 筆記: 15時間〜20時間 実技: 12時間 (去年4時間、今年8時間)

正直そんなに勉強に時間を使いたくなかったので、直前に詰め込む形で勉強。

筆記対策で購入したのはこのシリーズの2016年版。対策本と過去問。 amzn.to amzn.to

対策本を1周通しで読み、その後はひたすら過去問を解くという形。おそらく8割くらいはとれたんじゃないかな?

実技は工具セットと練習用材料キットを購入

http://amzn.to/2wvNazjamzn.to http://amzn.to/2exJlFcamzn.to

去年は練習用キットで一通り基礎の使い方を学んで、ホーザンのサイトで候補問題をいくつか動画視聴。ただ、正直これではまったくの準備不足でした。最終的には時間が不足し、残り数十秒というところでなんとか完成させたものの、チェックを行う時間すら無いという状況に陥ってしまいました。

電工試験の虎

今年は全ての候補問題の動画視聴&単線図⇒複線図起こしを行い、かつ器具の使い方や加工についても、頭で考えること無く手が動くように前日はひたすら反復練習。

結果として、試験時間5分前に完成させ、欠陥がないかチェックを行う余裕も持てました。

ということで、最終的には実技+筆記で30時間くらい費やしたかなという感じです。 今後チャレンジされる方は、筆記が簡単だからといって、実技で油断しないようにしましょう・・・

Pivotal Container Service(PKS)とその関連技術のはなし

既に各所でニュースになっていますが、アメリカで開催されていたVMworld 2017でPivotal Container Serviceが発表されました

[速報]VMware、vSphere上にコンテナ環境を自動構築する「Pivotal Container Service」発表。Google Container Engineとのポータビリティ実現。VMworld 2017 US

VMwareとPivotalが「Pivotal Container Service」発表-Google Cloudと協業

エンタープライズ向けKubernetesということで、大きく注目されたようです。

PKSの技術要素

PKSは、今年の春に発表されたKubo(Kubernetes-BOSH)を中心に、いくつかのVMwareテクノロジーを組み合わせた構成になっています。

f:id:jaco-m:20170831160429j:plain

Kubo

KuboはCloud Foundryでも使われているBOSHでKubernetesのデプロイと運用をしてしまおうという仕組みです。既に世の中にはいくつかのKubernetesのデプロイツールが存在していますが、これらはあくまでもデプロイをやってくれるだけ。実際に運用を行っていく上で必要なモニタリングやロギングなどの要素は別途作る必要があります。

ただ、Kubernetesのような大規模な仕組みの運用ってかなり大変なんですよね。でも、Cloud Foundryの運用ノウハウが詰まったBOSHを使うことで、そのあたりを一挙に解決できます。

BOSHをもっと知りたい、試したいという方は、makingさんのblogを参考にするのがよいでしょう

また、9/12に開催されるCloud Foundry Tokyo MeetupではBOSH祭りと称して、BOSHの基礎から利用事例まで幅広いセッションが予定されてますので、興味のある方はこちらも是非。

VMware Technology

k8sのオーバーレイネットワーク部分にはCNI準拠のNSX-Tが。 Docker RegistryとしてHarborが使われています。

Open Service Broker

GCPと連携するための仕組みとして、GCP Service Brokerが用意されています。 GCP Service BrokerはOpen Service Brokerに準拠しており、これを経由してGCPの各サービスのプロビジョニングやコンフィグレーションが行われます。

PKSのデモ

VMworldのKeynoteでは、PKSのデモも行われました。このビデオの0:52あたりを参照。 自分もPKSのデモは初めて見たんですが、おおすげぇ!ってなりました。こんなに簡単にk8sクラスタ作れちゃうのすごい。

実物触れるようになる日が楽しみですね。

MasterCloud #4で話しました

先日開催された MasterCloud #4 で、Cloud Foundryについてお話してきました。

発表資料はこちら

Dockerは便利だけど、自分でイメージの管理するとなると結構手間かかったりするんですよね。 自前でコンテナイメージの作成や管理できるのは便利なケースもある一方、手間ばかりかかって開発速度が落ちるというケースもしばしば。じゃあどうすれば?というときに、Cloud Foundryという選択肢も考えてみてはいかがでしょう という発表内容でした。

OpenServiceBrokerの話

OpenStackDaysのテクニカルセッションで話したスライドです。

個人的にCFで一番好きな機能がServiceBrokerなんですが、この仕様がCF特化ではなくてより汎用的になって、k8sをはじめとした他のプラットフォームからでも利用可能になるのが、このOpenServiceBroker。

CFの強みのひとつを外だししちゃっていいの?という気持ちはあるけれど、これでエコシステムが拡大するならばそれはそれでありなのかな。

Blogをはてなブログに引っ越した

これまでWordPressやGhostなどでBlogを書いていたけれど、そろそろ自前blogも面倒に感じてきた。

実際いちど、消してはいけないVPSアカウントを消してしまい、それまでのブログデータもろとも吹っ飛ばす事故やらかしてからは、もう自前でないほうがいいんじゃないかと。

データ吹っ飛ばす事件以降、blog書く気力も無くしていたので、この際引っ越してそっちで心機一転やろうかなと。

ということで、はてなブログに引っ越してPro契約。独自ドメインは過去のblogのものを引っ越し。 Ghostで書いていたデータはインポート出来なかったんだけど、たいした記事数もなかったんでひとつひとつコピペして引っ越し。markdownでかけるので単純にコピペするだけでよかった。

ということで、今後週1回くらいはかけるようにしたいなー。

あとデザインもちょっといじらないと。デフォルトだとあんまり好みじゃない。

k8sのService Broker改めOpen Service Broker APIについて

先日書いたこの記事

k8sが導入するService Brokerの仕組みとは

ですが、Open Service Broker APIとしてサイトが出来ていました。

GitHubのリポジトリはこちら

Open Service Broker APIのspecはこのドキュメントにまとめられていくようですが、現時点ではCloud FoundryのService Broker APIそのものになっていますね。

CF Service Broker APIは、Cloud Foundryにしかないorganization_idspace_idといったパラメータが必須項目になっており、このままではk8sやOpenShiftで利用するのは難しいでしょう。

今後このあたりのCF特化の項目が取り払われていき、より汎用的なAPIになってくのかなと考えられます。

議論はSlackやGoogleGroups/MLで進められていくようなので、興味のある方は参加してみてはいかがでしょうか。

HUISリモコンとNode-REDを繋げるやつの仕組み

Node-RED Advent Calendar 2016の14日目!

以前、Node-RED UG勉強会 Vol.1 で発表したHUISとNode-REDの連携のやつですが、とある人から仕組みを教えてくれと言われてました。

・・・が、すっかり失念しておりました(すみません)

ということで、Advent Calendarにあわせてあれの仕組みを書いてみます。

先にHUISの話

ソニーのハイテクリモコン、HUISですが、発表の後も順調にアップデートされています。先月にはHUIS UI Creator ver 2.0、HUISソフトウェア ver 4.0が出ています。

http://huis.jp/

特にHUISソフトウェアは、10月に出たver 3.1から本体の動作速度が劇的に向上しており、かなり使い勝手が良くなりました。

赤外線連携部分

HUIS x Node-REDと書いてますが、正確には赤外線リモコンのデータをNode-REDで受け取って処理するという話なので、これから書く内容は普通のリモコンでも同じように利用できます。

赤外線受信

赤外線の受信には、BitTradeOneから出ているUSB接続 赤外線リモコンKITというのを使っています

公式に提供されているツールはWindows用なのですが、Linuxで利用できるコマンド btr_ir_cmd というものがGitHubで公開されているので、今回はそれを利用しました。

https://github.com/kjmkznr/bto_ir_cmd

このコマンドで受信も送信も可能なのですが、今回は受信のみを使います。

$ sudo bto_ir_cmd -r
Receive mode
  Received code: C1AA5A8F302081

赤外線を受信すると、このようにコードが表示されます。

Node-REDとの連携

bto_ir_cmdだと、待機中に表示される文字列が邪魔だったので、以下のようなシンプルなラッパーを書き、btoというコマンド名にしました。

#!/bin/bash
echo `bto_ir_cmd -r | grep code`

フローについては

  1. Node-REDのexec nodeを使ってbtoを実行(待ち受け状態になる)
  2. 信号を受信すると標準出力が得られるので、出力をパースしてコードを取り出し
  3. コードごとにswitch nodeで処理を分岐。分岐させたあとはお好きなように
  4. exec nodeをループさせて再度btoを待ち受け状態に

という流れでやっています。

Node-REDでbto_ir_cmdを叩くフロー

ハマったポイントとしては

  • exec nodeでは、"Use spawn() instead of exec()?“ にチェックを入れること(標準出力と、さらにReturn codeをloopに使うため)
  • bto_ir_cmdではExtendedモードを使わないこと
  • Extendedを使うと大幅にレスポンスが悪化し、実用に耐えなくなる

くらいでしょうか。フロー自体は非常にシンプルなので、Node-REDに慣れている方であればすぐに応用できると思います。

Gistにフローを貼っておいたので必要であれば参考にしてください。 https://gist.github.com/jacopen/72468a6176162e9a88f5cf5f654750b5

最後に

勉強会資料の最後にもちらっと書いてますが、HUISはBluetoothに対応しており、8月にはBluetooth対応のクレードルも出ました。

Bluetoothを使えば連携の幅をさらに広げることができるので、こちらのほうも試してみたいなーと考えてます。