tech.guitarrapc.cóm

Technical updates

Yamaha NVR700W で Nuro Biz と接続してみる

たまにはインフラっぽい記事を書きます。

一昨年から個人的に話題になっているサービスといえば Nuro Biz です。強力なバックエンド、G-Pon、ダークファイバと、多くの先見性と高速さ、コストの安さが謳い文句に良く聞きますよね?

さて、昨年 2016年9月に Nuro Biz と Yamaha NVR700W をIPoE接続する機会があったので、今回はその接続設定についてです。従来の PPPoE とは異なる設定になるので、参考になる方がいらっしゃれば幸いです。

目次

Nuro Biz

開通までの流れを見てみましょう。

開通まで

Nuro Biz 営業さんと、要件、プラン、開通までの流れ、開通予定日を決めます。結構分かってる営業さんが多いのか、話が非常にスムーズに進み、色々教えていただきました。ありがとうございます。

確認事項 概要
要件 小規模なこともあり、下り 2Gbps あれば十分、固定IP が一つあればいいでしょう。
プラン これを満たす必要十分なプランとしてスタンダードに秒決でした。
開通までの流れ 申し込み、契約署の取り交わし、工事前下見、引き込み工事/ONU工事、利用開始 の流れです。
開通予定日 工事などから逆算です。通常 4-6週、すでに同ビルで Nuro Biz利用者がいる場合はもう少し短くなります。

プラン

今回接続に利用したのは、次のプランです。

http://biz.nuro.jp/service/spec/

項目 内容
プラン NUROアクセス スタンダード
固定IPv4 標準 x1
固定IPv6 標準 x1

申し込み

申し込みは、PDF で捺印後に返信、口座支払い/クレジットの場合は支払い登録書の送付が必要になります。

下見

申し込み完了後は、Nuro Biz から NTT にダークファイバの申請が行われます。この申請完了までが時間がかかるため、開通までに最も影響します。

また、申請を行うにあたり、すでに同ビルでの利用があるかが確認されます。もし利用がない場合は、ダークファイバの引き込み、一部中継機器の設置が必要になるため、下見が発生します。ビル管理担当者様や下見立ち合いの調整が必要になるため、いい感じでやりましょう。

当然、MDF/EPS への立ち入りも発生するため、ビル管理担当者様にはその旨の連絡、鍵のお願いも必要です。

下見に関しては、手慣れていらっしゃることもありサクッと30分程度で終わります。問題なく行けそうでも、一部不安があってもNTTへのダークファイバの空き状況確認/準備確認、当日調整も行ってくれるあたりは結構知見もたまっていらっしゃてスムーズにすすめようとされている姿勢が垣間見えます。

当日作業

NTT 側のダークファイバ作業、Nuro Biz 側の回線引き込み作業を同日、同時刻に行っていただくことができます。MDF立ち入りなどもあるため、日程が圧縮、同時進行できるのは非常に助かります。

非常にスムーズで、大変素晴らしいお手並みでした。プロです。

NVR700W

さて、回線が引き込まれて ONU が設置されたら接続試験をやっていっていただけます。とはいっても、ONU直のままではこまるので、早速ルータとして NVR700W をかませましょう。

2016年7月発売ということで、発売からあまり時間をおかずに設定でしたが UI も RTX810 から一新されポートも見やすく非常に良くなっています。強い。です。

http://jp.yamaha.com/products/network/routers/nvr700w/

経路図

Nuro Biz に限らずネットワーク回線と接続設定するときには経路図が重要なのはいつものことです。というか、これがないと話になりません。

重要なポイントが以下の3つです。図とともに読み合せることをでルータのコンフィグを構成します。

  • 固定IPアドレスオプションは、局舎から見て①をネクストホップとしたスタティックルーティングが設定されています
  • LAN1ポートでは固定IPアドレス設定を推奨しますが、DHCP設定で接続すると、他の機器への交換の際、最大3時間DHCPが動作しません。その場合は、一度IPアドレスを開放していただくか、交換する機器に固定IPを設定して接続ください(IPv4の場合)
  • LAN2ポートに接続するとDHCPにより動的にプライベートまたはグローバルIPv4が1つ割り振られます(複数ルータは接続できません)。他の機器への交換の際、最大60分間DHCPが動作しません

構成図

今回は小規模な構成で行きます。単純ですね。

NURO 光 ONU <WAN>
  (LAN1)
     ┗ (WAN) Yamaha NVR700W <ルータ>
              (LAN1)
                 ┗ (Port n)基幹L2スイッチ <LAN>

NVR700W Config

さて、NVR700W のコンフィグを書いてみるとしましょう。

様々なサンプルを Yamaha さんは公開されています。

http://jp.yamaha.com/products/network/solution/internet/

しかし、IPoE は 良くある PPPoE とも異なります。

pp select 1
pp always-on on
pppoe use lan2
pp auth accept pap chap
pp auth myname (ISPに接続するID) (ISPに接続するパスワード)
ppp lcp mru on 1454
ppp ipcp ipaddress on
ppp ipcp msext on

一番近いのがこれですが、あいにくと Nuro Biz にちょうど該当する IPoE 構成は公開されていません。

http://jp.yamaha.com/products/network/solution/flets/flets_other_service/flets-next-ipv6_ipoe-rtx1200/

一からコンフィグを書きます。入力にあたり各種設定は次の通りです。 *1

IPv4 パラメータ
標準固定IPv4 (WAN Port IP Address) 98.76.54.32
サブネットマスク (Subnet Mask) 255.255.255.192 (/26)
デフォルトゲートウェイ(Default Gateway) 98.76.54.30
IPv4 DNS (Primary) 123.123.123.123
IPv4 DNS (Secondary) 123.123.123.139
IPv6 Parameter
標準固定IPv6 Prefix(IPv6 Prefix) 123a:001b:0045:6700:: / 56
IPv6 DNS (Primary) 123a:0040:0005:0005::33
IPv6 DNS (Secondary) 123a:0040:0005:0006::49
LAN Parameter
LAN側 IP 10.0.0.1/24
LAN側 DHCP Scope 10.0.0.2-10.0.0.100/24
ntp ntp.nict.jp

コンフィグは次の通りです。今回は IPv4 でサクッと組んでみました。

gist.github.com

構成後

簡易接続速度試験を行っても、速度低下もなく非常にスムーズであることが分かります。同時接続が増えても十分に速度を維持しているのは非常に助かります。

接続経路 Download Upload スクリーンショット
Nuro ONU - PC 直通テスト 892.70Mbps 818.49Mbps
Nuro ONU - NVR700W 911.36Mbps 930.43Mbps

まとめ

NVR700W でも全く問題なく Nuro Biz と接続ができるので安心して使うといいでしょう。Yamaha せんせーは、サイトにサンプルあると非常に助かるのでぜひぜひこういったサンプルも増やしてもらえると嬉しいですね!

*1:架空の値なので、ご自分の環境に置き換えて読んでください

個人名刺を作った

昨年、いい機会なので個人名刺を作ってみました。今回はその備忘録です。*1

実物は名刺交換した時にお確かめください。

目次

個人名刺とは

あなたにとって名刺はなんでしょうか?

自分にとっては自己表現のための道具の1つと位置付けています。端的に言うと、自分のことを何も知らない誰かと会ったときに自分を伝えるツールです。個人名刺もビジネス名刺と同じ役割を期待しています。

個人名刺を利用する時

個人名刺を利用するのは私的な関わり(技術の有無を問わない) をする時です。

初対面の方とコミュニケーションをとるとき、特に直接対話をする場合はお互いに何かしら話のネタがあった方がスムーズになりやすいと思っています。別に天気の話でもいいのですが、興味のない話をお互いに行うのは時間を無為にするだけなのである程度ロスを減らしたいです。

wol.nikkeibp.co.jp

mensdrip.com

tabi-labo.com

そこで個人名刺である程度の情報を明示的に伝えることが出来れば、「お互いに有益なスタート」になる可能性が高いかなぁと。また、名刺が手元にあれば、本などと同じように「ふと名刺やEightで見かけたときにどんな人だったかな?」となるきっかけになると嬉しいものです。

個人名刺を持っていた時

実は、5年ほど前に個人名刺を持っていました。当時自分で個人名刺を作ったのは、勉強会などのコミュニティ参加するにあたり会社からは切り離された自分を表現する必要があったためです。当時の会社では個人活動を全く持ち込んでなかったので、自分にとっての公私混同を防ぐ役割がありました。100枚余り自作して、使い果たしてからは刷りなおさずにいます。*2

個人名刺を再度作らなかった理由

さて、グラニにジョインした後は、コミュニティ活動も応援してくれる会社であったことに加えて、仕事内容 == 自分の興味のあること == コミュニティ活動だったため、会社名刺のみでいました。会社がコミュニティ活動を応援してくれるというのは嬉しいものです。グラニもコミュニティ活動を応援してくれているので、ご興味のある方はぜひぜひ。*3

個人名刺をまた作る理由

ここ2年で、個人的な知人とのやり取りが少しずつ増えるに従い、個人名刺がほしくなってきたのが理由です。知人からすると仕事としての自分はどうでも良く、個人としての自分だけを見られるためいい加減作らないとなぁと思っていたのでした。

せっかく作ったので、勉強会でも交換する機会があれば積極的に使っていきたいところです。

個人名刺の作成

どんなことを考えて、どうやって名刺を作ったかメモしておきます。名刺交換する機会がありましたら、よろしくお願いいたします。

載せる情報の選別

名刺は限られたスペースです。「他人のことなんて興味ないのが普通」だと個人的に考えているので、乗せる情報も端的かつ興味を持ってほしいことに選別しました。*4

また、経験上情報を増やすことは簡単ですが削ることは難しいため、名刺に載せる情報は2つに絞ることにしました。

  • コミュニケーションをとる窓口(表面)
  • 自分がどんなことに興味を持ち力を発揮できるのか(裏面)
コミュニケーションをとる窓口(表面)

今現在良く利用される方法としては、携帯、メール、Twitter、Facebook、G+、ブログ、Skype、Line、各種アプリ他もろもろと様々な手段があります。これに、SteamやOculusをはじめとして様々なツールのIDまで含めるとキリがありません。

日本だけではなく海外でも渡す機会があるので、相手のことを考えると方法を豊富に用意しておくのも手でしょう。しかし、活動がめったにないものを掲載したところで、自分が気づけなければ意味がない上に不誠実だと思っています。

結果、Twitter ID の @guitarrapc_tech とこのブログのアドレス http://tech.guitarrapc.com だけを載せることにしました。事実上連絡手段がTwitter 1つだけというのは良く無いと思うのですが、Twitterだと確実に反応できるのでいったんはこれで。*5

自分がどんなことに興味を持ち力を発揮できるのか(裏面)

ようは自分のスキルブックです。冷静に、誇張なく、自分が力を発揮できるものとしてスキルを考えると大まかに5つが挙げられます。

  • C#
  • PowerShell
  • VR
  • Unity
  • Cloud Infrastructure

ここから、発揮するために努力を今現在継続しており、発揮したいと思っているものに選別して対象とするとPowerShell が除外されます。

  • C#
  • VR
  • Unity
  • Cloud Infrastructure

わかりやすく伝えるためにはカテゴライズが必要とかんがえたので区分してみると3つになりました。

  • 言語として力が発揮できること : C#
  • 自分が今力を入れて取り組んでいること : VR 開発に Unity を利用 *6
  • Cloud Infrastructure : 自分が得意として多くの経験を厳しく積んでいるもの

この3つが伝えられれば過不足なさそうです。*7

今自分ができることってなにかなぁと振り返るのは大事だなぁと思うことがたびたびありますが、名刺作成もいい機会でした。

名刺デザイン

自分が相手に伝えたいことは決まりました。次はいかに伝えるかということでデザインの力です。名刺自体は極めて広範に使われており、先人の考え抜かれたデザインをググって参考にできます。しかしながら、圧倒的なデザインセンスのなさを痛感しているため自力で考えるのはそうそうに諦めました。

幸いにも、知人経由でデザイナーの方を紹介していただけそうというお話をもらったので、お仕事を依頼することにしました。デザイナーの方に名刺デザインを依頼するからには、具体的にデザインできるように何を伝える必要があるのかを知人に相談しつつ書き出しました。

デザイナー/自分 内容
デザイナーさんにお願いすること 名刺全体のレイアウトデザイン
デザイナーさんにお願いすること アイコンデザイン (x4)
デザイナーさんにお願いすること 名刺入稿
自分がやること 名刺を不透明、透明にするのかの確定
自分がやること 名刺にのせる情報の選定
自分がやること 名刺をどう見せたいのかのレイアウトイメージ
自分がやること 欲しいアイコンイメージ
自分がやること 自分の好みの色合いを明確にする

デザインイメージのやり取り

今回依頼することは名刺デザインに加えて、アイコンの作成も含んでいます。直接会うこともないため、どこまで具体的に伝えられるかがポイントと考え、お互いのGoogle Drive にスライドで書き出して具体的なイメージを伝えることにしました。

一番初めのスライド依頼では、名刺表裏のレイアウトイメージ、素材を紙とすること、作成してもらうアイコンのサンプル、好みの色合いなどなどを書き出しています。

当初案がこれです。表面が連絡先、裏面がスキル的な。

また、Google Drive を使ったのはかなり良くて、イメージを明確に過不足なく伝えることができるツールとして非常に優秀でした。Prott とかもいいのですが、個人利用にはGoogle Drive 最高ですね。

名刺デザインの進捗

私が特に急ぎではないこと、相手もお仕事がある合間ということで、進捗は週1回の週末にゆっくりと進みました。タイムラインは次の通りのようです。

日付 進捗
2016年11月6日 依頼開始
2016年11月28日 デザインが確定
2016年12月3日 名刺素材確定
2016年12月10日 入稿

結果としてみると、当初のデザイナーさんの予定通り12月上旬に完成しました。*8

アイコンデザイン

アイコンデザインはかなり面倒なお願いと思いつつもお願いしてみました。当然のごとく最も時間がかかり、デザイナーの方にも様々な案を出していただきました。*9

作成したアイコンは4つです。

  1. Twitter アイコンっぽいもの *10
  2. C# とわかるもの
  3. VR的なもの
  4. クラウドインフラ的なものという要素です

特にC# と VRアイコンには難儀しました。当初案に対してすぐにデザイナーさんから案もいただいたのですが、この後もお互いの試行錯誤が続きました。なかなかイメージを確定できなくて申し訳ないと思いつつ、様々なデザイン案でイメージを明確に形にしてくださったことに感謝が絶えません。

クラウドに関しても、おぼろげに考えていましたが AWS も Azure も良く考えているのですね。*11 デザイナーさんとやり取りする中で、アイコン1つ一つの意味をすごく考える機会になりました。

アイコンには文字を添えており、アイコンと合わせて1つの意味を表すようにしています。

レイアウトデザイン

アイコンが定まったことでレイアウトが一気に決まります。表面は当初案から変わっていませんが、裏面はアイコンが定まるまで色イメージと配置が確定しませんでした。様々なバリエーションを提示していただいたのです。

当初はこんなレイアウトだったので雲泥の差です。

実は、最終的に決まったのはおまけとして提示された四角に納めずフリーに配置するものでした。やはりデザイナーさんが自由に発想すると素敵なものが生まれるなあと思った瞬間でした。

用紙選定

入稿までお願いしてしまった甘えっぷり。入稿のルール難しいですねぇ。印刷についても学べました。

さて、今回のデザインでの発色を考慮した紙も提案していただきました。感謝しかありません。提案された紙を調べる時に、紙の素材やどういう性質なのか調べるのが楽しかったです。名刺屋さんのサイトは豊富に情報があってみてるだけで楽しくなります。

http://www.meishiryohin.com/paper/www.meishiryohin.com

どの紙を選んだかは内緒です。ぜひ手に取ってみてください(?)

デザイン依頼料金

依頼料は相場を調べつつ、デザイン料金 + 入稿時の名刺印刷代 でお願いしました。やり取りの質からも、次にお願いすることは間違いありません。

https://crowdworks.jp/lp/cl/competition/business_cards/articles/432crowdworks.jp

takahitoart.com

http://www.nexgate.jp/contents/printing_letter/mh3_3.htmlwww.nexgate.jp

まとめ

なんというか、依頼したデザイナーさんが本当に心から神でした。個人名刺に限らず、末永くお付き合いをお願いしたいと思うとともに、甘えすぎているのでもっと勉強しようと誓うのでした。

個人名刺はいいぞ。素敵なデザイナー様に巡り会えると本当にいいぞ。今ある名刺が掃けたら半透明とかいいなぁとかなんとか。

実はブログのアイコンも併せて変えました。

*1:ポエムなので嫌いな人はスルー推奨です

*2:すでに作ったデータも失っているようです...

*3:とはいえ時間は有限です。コミュニティ活動が好きで時間が有限ということは、たやすく仕事に影響もしやすいものです。良い影響ならともかく、疲れ果てるなどどちらかがどちらかに悪い影響を与えるというのは私にとって最も嫌うことです。どっちも大事ならどっちも尊重しないと、ね。これが崩れると公私混同の始まりと考えています。このあたりのバランスは、CTOのneuecc にコミュニティ活動を相談しつつ、会社のスペースで勉強会を開いたりと活動していました。

*4:情報が少なければ目を通されてスルーされる量も減るのでより良い

*5:http なのが非常に嫌なのですが、現時点では仕方ありませんhttp://imaarumono.hatenablog.com/entry/https

*6:AR/MR/VRとか細かいことはここではどうでもいいです

*7:PowerShell 足してもいいのですがツールを載せることの意味は長年グラニの名刺でMVPとして表示していて意義を感じなかったのでイラナイデス

*8:スケジュール感すごい...!

*9:積極的に素敵なデザイン案を出していただいて本当に感謝しています

*10:これは瞬殺で終わりました

*11:GCPお前は違う

AzureFunctions の Precompiled Functions を試してみる

2017/1/6 に Precompiled Functions がサポートされました!! この対応により、C# Scripting (.csx) に比べてかなり Azure Functions が書きやすくなります。早速Precompiled の利用とこれまでの.csxとの違いを見てみましょう。

buchizo.wordpress.com

目次

Precompiled Function の概要

「ビルド済みのdll」 と 「dllを使うことを明示した function.json」 を設置することで、.csx で発生していたコンパイルがスキップされ指定したメソッドをエントリポイントとして関数が実行されます。

2017/1/13 現在、.NET Framework v4.6 (Full Desktop) がdllの対象となります。このバージョンは Azure App Service の制限となるので、将来の.NET Framework 対応はそれ待ちです。

なお、.NET Core 対応 はされていません。すでに Issue に上がっていますが、Microsoft.Azure .WebJobs をはじめとする ライブラリやAPIの解決が待たれる状態です。これができると、AWS Lambda とのマルチクラウドにおけるコード運用も可能になるので、かなりいいのですが..。

github.com

github.com

実際、最新の 1.1.2 を試してみても、ね?

さて、改めてPrecompiled Functions を使う理由ってなんでしょうか? 個人的には、.csx で解消できなかった IDE 支援の下でのC#の記述、dllコンパイルによる挙動のわかりやすさ、ローカル環境での動作検証の容易さがその使う理由です。

Pros

ザクッとあげます。要は普通にC# が Visual Studio などのIDE支援で書けるのって嬉しいですね、デプロイ不要でローカルデバッグできるのいいですね。ということです。

メリット一覧 内容
IDE のフル支援が受けられる Visual Studio や VS Code をはじめとする任意のIDEでいつも通りC#を書けます。.csx では、インテリセンスをはじめとしたIDE支援が制限された中で書くことが強いられていたため、普通にかけるのは嬉しいものです。
ローカル動作の確認 dllにコンパイル済みなので、些細なミスによるコンパイル失敗は完全に避けられます。些細なのですが、; 忘れだったり結構IDEに頼っていることを自覚させられる生活から解放されます。*1
一定の動作保証 ローカルで動作確認した上でCI/CDするため、おおよそ意図通り動くことが期待できます。*2
Cons

WebUI での編集ができない。の一言です。AWS Lambda における Java や C# (.NET Core) と同じです。

実際、Precompiled Functions は WebUI 上でみてもコードは表示されず文字化け状態で表示されます。*3

Precompiled Functions を作成してみる

ミニマムコードサンプルはWikiにあります。

github.com

今回は、ミニマムコードにない Logger を含めてやってみましょう。コードはいつも通り、Github に挙げておきました。PrecompileFunctions.sln にソースをいれてあります。

github.com

コード全体像は次の通りです。

gist.github.com

このプロジェクトをビルドすればルート直下にPreCompileEnvironmentVariables フォルダを作成して、ビルド済みdll、function.json が一緒に配置されます。ちなみに、nuget パッケージを一切追加しない状態だと次のようなエラーが出ます。そこで、必要なパッケージを追加して解決しています。

テストすると、上手く動きましたね?

エントリポイントのメソッドを含めるクラスの注意

dll を配置した場合のエントリポイントは、function.json に記述した次の2文で指定します。

  "scriptFile": "PreCompileEnvironmentVariables.dll",
  "entryPoint": "PreCompileEnvironmentVariables.MyFunction.Run",
キー 設定する内容
scriptFile コンパイルしたエントリポイントとなるdll を指定します。
entryPoint NameSpace.Class.Methodの形式でエントリポイントを指定します。

例では、MyFunctionクラスのRunメソッドをエントリポイントに指定しています。このRunメソッドを含む MyFunctionクラスには、Runメソッド以外を含めるとエントリポイントを見つけられないようです。つまり、インスタンスフィールドなどは書かず、Runメソッドだけ書いてください。

ロガーについて

ロガーを利用するには Microsoft.Azure.WebJobs nugetパッケージの追加をしましょう。ミニマムコードのRunメソッドシグネチャに TraceWriter がありませんが、実は渡ってきています。このnugetパッケージがあれば、.csx 同様にTraceWriter を実装せずともロガーとして利用できます。

これにより、エントリポイントのメソッドシグネチャはpublic static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)のように書けます。これでこれまで通り、log.Info("なにかログ") とするだけでロギングできて便利!

HttpRequestMessage の拡張メソッドについて

.csx と同じように HttpRequestMessage の拡張メソッドを利用するため、Microsoft.AspNet.WebApi.Core nuget パッケージの追加をしましょう。これにより、HttpResponseMessage CreateResponse<T>(this HttpRequestMessage request, HttpStatusCode statusCode, T value) などが利用可能になります。

Precompiled Functions をデプロイする

いよいよ Precompiled Functions をデプロイしましょう。Github による CD でやってみます。

従来の deployment.cmd に msbuild のセクションを追加しました。diffはこの通りです。

gist.github.com

上手くデプロイされるとFunctions がビルド後に展開され、WebUI からも見えるはずです。

ただし、w3wp.exe による dll ロック問題があるので、2度目以降のデプロイ時には Kudu コンソールで w3wp.exe をkill、WebUIでのRestart をしてあげてください。

この問題はすでに報告済みなので、解決を待ちましょう。*4

github.com

Precompiled Functions の課題

いくつか使いにくいポイントが残っています。

ビルド

今回、.slnの配置、ビルド生成物の配置をいじっていますが、CI -> CD の連携に工夫がいるのはちょっとまだ使いにくいかと思います。もう少しいい感じでデプロイできるといいのですが...。

DLLロック

現状では、Web Apps の API経由、Kudu API 経由などで w3wp やサイトのリスタートが必要です。結構ヤなポイントなので、これは解消しないと使いにくいです。コンテナベースになれば手っ取り早いのですが...。

.NET Core 対応

いずれするでしょう。待ちです。

まとめ

かなりいい感じで利用できると思います。dll の文字化けが表示されるのは愛嬌ということで。

が、dllロックは結構厄介なので、これが解消するのを待って本番に入れたいところです。AWS Lambda が主軸なのですが、サブとして Azure Functions は優秀なので、.NET Core 対応も待ち望ましいですね。

*1:その自覚別にうれしくないです

*2:環境依存の原因で動かないことはあり得るのでそこはしょうがない

*3:まるでdll をエディタで開いた時のような画面ですね

*4:Kudu Deployment Script でやるかと思いましたが、まぁ待機で。

.NET Core on Lambda で Unity Cloud Build のWebhook処理とLambda をネスト実行する

今回は、Unity 開発に欠かせない存在になってきた Unity Cloud Build のビルド通知をAWS Lambda (.NET Core) でいい感じに処理することを考えてみます。手始めに、他のチャット基盤 (Chatwork) への通知に取り組んでみましょう。

結果こんな通知がくるようにします。

Zapier 連携があればもっと楽ちんだったのですがシカタナイですねぇ。

目次

Unity Cloud Build とは

Unity Cloud Build は、Unity の SaaS型 CI サービスです。

βのころからずっと触っていましたが、なかなか癖が強いのとUnity ビルド自体がマシンパワー必要なのに対してビルド環境がそこまで強くない、UIが使いにくい、アクセス制御が乏しいなどと難しさをずっと感じていました。しかし、ここ3か月の進化は正当に順当に進んでおり少なくともUIやグループ制御もいい感じになってきました。

加えてビルド状態がWebhookで通知できるようになってことで、他基盤との連携がしやすくなりました。

blogs.unity3d.com

Slack がデフォルトでワンポチ連携できるのもトレンドに沿っててなるほど感。

とはいえ、このままではほかの基盤と連携するには Webhook を受けて解釈する必要があります。こういったイベントベースの連携には FaaS がまさに向いています。AzureFunctions でも API Gateway(やSNS) + AWS Lambda、あるいは Cloud Functions が格好の例でしょう。

今回行うのはまさにこの、Slack 以外のサービス基盤と Webhook を使って連携することです。連携したいサービスは Chatwork、連携を中継するのは API Gateway と AWS Lambda です。*1

全体像

まずは今回の仕組みで利用する構成です。構成要素は以下の通りです。

  1. Unity Collaborate
  2. Unity Cloud Build
  3. Amazon API Gateway
  4. AWS Lambda
  5. Chatwork

全体図です。

簡単に見ていきましょう。

Unity Collaborate

Unity のソース をチームで共有するための仕組みで、今回は Unity Cloud Build へのソース、イベント発火起点として利用します。

Unity Cloud Build

今回の肝となるCIです。やりたいことは、ここで発生したビルドイベントのWebhookを経由した他サービスとのイベント連携です。今回のイベント連携終着点はChatwork への通知ですね。

Unity Cloud Build の通知先が Slackなのであれば、Cloud Build の通知先にビルトインされているので、API Gateway も Lambda も使わず簡単に飛ばせます。仕組みは単純に Unity Collaborate -> Unity Cloud Build -> Slack、シンプルですね。

Amazon API Gateway -> Amazon Lambda -> Chatwork

Amazon API Gateway は Webhook を受けて Lambda に流しこむためのプロキシとしての役割を担います。

AWS Lambda は、イベント連携の基盤です。どのように連携するかをコードで定義します。言語は C#(.NET Core)を使ってみます。

最後に、AWS Lambda からChatwork にビルド情報を送信します。

Unity Cloud Build の Webhook API 仕様

さて、Lambda で解析する Unity Cloud Build から送られてくるWebhookメッセージフォーマット の仕様はドキュメント化されています。

Unity Cloud Build

application/json で送られてくるJSONフォーマットは次のものです。

{
    "projectName": "My Project",
    "buildTargetName": "Mac desktop 32-bit build",
    "projectGuid": "0895432b-43a2-4fd3-85f0-822d8fb607ba",
    "orgForeignKey": "13260",
    "buildNumber": 14,
    "buildStatus": "queued",
    "startedBy": "Build User <builduser@domain.com>",
    "platform": "standaloneosxintel",
    "links": {
        "api_self": {
            "method": "get",
            "href": "/api/orgs/my-org/projects/my-project/buildtargets/mac-desktop-32-bit-build/builds/14"
        },
        "dashboard_url": {
            "method": "get",
            "href": "https://build.cloud.unity3d.com"
        },
        "dashboard_project": {
            "method": "get",
            "href": "/build/orgs/stephenp/projects/assetbundle-demo-1"
        },
        "dashboard_summary": {
            "method": "get",
            "href": "/build/orgs/my-org/projects/my-project/buildtargets/mac-desktop-32-bit-build/builds/14/summary"
        },
        "dashboard_log": {
            "method": "get",
            "href": "/build/orgs/my-org/projects/my-project/buildtargets/mac-desktop-32-bit-build/builds/14/log"
        }
    }
}

さぁこれで全体の仕組み、メッセージフォーマットがわかったので、API Gateway で受けてLambda で好きなようにいじれますね。Unity側の設定、AWS側の設定と順にみていきましょう。

(Unity 側設定) Unity プロジェクトの Collaborate 設定

Unity Cloud Build のビルド連携は、Unity Collaborate 経由が一番楽です。Github 空の連携では、Submodule や ビルド依存関係(dllがビルド時生成とか) など細かい制御が非常に面倒です。*2

今回は Unity の VRプロジェクト*3をビルドする体で進めます。

適当にUnityで新規プロジェクトを3Dで作成して、SteamVR Pluginを追加します。

Steam VR Plugin

デフォルトシーンにある main cameraを削除して、SteamVR Plugin の CameraRig を追加します。

続いて、メニューバー > Windows > Servicesを開きます。

Unity Editor に表示された ServicesタブでUnity Collaborate を有効化、Collab から Publish now!します。

Upload が終わるのを待ちます。

(Unity 側設定) Unity プロジェクトの Cloud Build 設定

Upload 後は、Cloud Build を有効化して、

環境に合わせてビルド設定を組みます。*4

ビルド設定が追加されると、自動的にビルドが開始します。Unity Collaborate で publish したら自動的にUnity Cloud Build も走るように設定できるので非常に楽ちんですね。*5

ビルド完了も Unity 上から確認できる上に、Cloud Build の Web へのリンクもあるので Web上でも確認できます。このあたりの連携は非常に便利です。うれしさあります。

さて、これで Webhook でビルド通知を流す下準備ができました。次は AWS 側の設定をやります。

(AWS 側設定) Lambdaの連携方法

AWS 側で必要なのが、AWS Lambda の構成 -> API Gateway の構築です。いわゆる AWS Serverless Application Model(SAM) と呼ばれるやつです。

New for AWS Lambda – Environment Variables and Serverless Application Model (SAM) | AWS News Blog

github.com

この流れで SAM にするとコンポーネントが増えてしまいます。リトライ回りやフロー化という意味ではStep Functions とかも面白いのですが、今回はシンプルに行きましょう。

ふつーに API Gateway + Lambda とします。

(AWS 側設定) Lambda から Lambda の呼び出しのIAM Role作成

通常のLambda 単独実行ならば、いわゆる lambda_exec_role があれば実行できます。Managed Policy の AWSLambdaExecute がそれですが、こんなデフォルトポリシーですね。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:*"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::*"
    }
  ]
}

しかし、Lambda から別の Lambda を呼ぶには lambda:InvokeFunction 権限が必要です。Managed Policy の AWSLambdaRole がそれにあたります。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "lambda:InvokeFunction"
        ],
        "Resource": ["*"]
    }]
}

ということで、IAMに lambda_collaborate_role を作っておきましょう。

(AWS 側設定) Lambda の構成

Unity Cloud Build の Webhook を受けて実行する Lambda を作成します。また、Lambda から SendToChatwork Lambda を呼び出します。*6

Lambda のコード

ざくっと行きます。

  • Function.cs が、今回の AWS Lambda本体コードです。Chatwork でメッセージが読みやすいようにいい感じに整形します
  • UnityCloudBuildWebhook.cs は JSON からクラスへのデシリアライズ定義です
  • ChatNotification.cs は、以前作成した Chatwork への送信 Lambda に渡すクラス定義です
  • project.json に、今回利用するコンポーネントを記述しています
  • aws-lambda-tools-defaults.json には、先ほどの IAM Role などを記述します

gist.github.com

入力されるJSONについて

API Gateway で body : Webhokで送信されたJSON となるように整形します。こうすることで、body経由で入力があったのかどうかも含めてシチュエーション対応が柔軟にできます。

そのため、Lambda で受けるJSON は次のフォーマットになります。

{
  "body": {
    "projectName": "My Project",
    "buildTargetName": "Mac desktop 32-bit build",
    "projectGuid": "0895432b-43a2-4fd3-85f0-822d8fb607ba",
    "orgForeignKey": "13260",
    "buildNumber": 14,
    "buildStatus": "queued",
    "startedBy": "Build User <builduser@domain.com>",
    "platform": "standaloneosxintel",
    "links": {
      "api_self": {
        "method": "get",
        "href": "/api/orgs/my-org/projects/my-project/buildtargets/mac-desktop-32-bit-build/builds/14"
      },
      "dashboard_url": {
        "method": "get",
        "href": "https://build.cloud.unity3d.com"
      },
      "dashboard_project": {
        "method": "get",
        "href": "/build/orgs/stephenp/projects/assetbundle-demo-1"
      },
      "dashboard_summary": {
        "method": "get",
        "href": "/build/orgs/my-org/projects/my-project/buildtargets/mac-desktop-32-bit-build/builds/14/summary"
      },
      "dashboard_log": {
        "method": "get",
        "href": "/build/orgs/my-org/projects/my-project/buildtargets/mac-desktop-32-bit-build/builds/14/log"
      }
    }
  }
}
Lambda から Lambda の呼び出しにおける project.json に注意

今回 Lambda から Lambda を呼び出しました。この時利用するのが、Amazon.Lambda.AmazonLambdaClient です。この利用には少し注意点があります。AmazonLambdaClient クラスはAmazon.Lambda.Toolsパッケージで入るように見えます。しかし実際のところは、Amazon.Lambda.Toolsが依存しているAWSSDK.Lambda が本体です。

このため、project.jsonAWSSDK.Lambda を参照しないと、コンパイルが通っても実行時エラーになります。AmazonLambdaClientクラスを利用しない限り出会わないため気付くのが遅れやすいくて苦しかったです。

実行時エラーになる例

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0"
    },
    "Amazon.Lambda.Core": "1.0.0*",
    "Amazon.Lambda.Serialization.Json": "1.0.1",
    "Amazon.Lambda.Tools": {
      "type": "build",
      "version": "1.0.0-preview1"
    },
    "Newtonsoft.Json": "9.0.1",
    "LambdaShared": "1.0.0-*"
  },

  "tools": {
    "Amazon.Lambda.Tools": "1.0.0-preview1"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
}

エラーメッセージ

{
  "errorType": "FileNotFoundException",
  "errorMessage": "Could not load file or assembly 'AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604'. The system cannot find the file specified.",
  "stackTrace": [
    "at UnityCloudBuildNotificationProxy.Function.FunctionHandler(Object input, ILambdaContext context)",
    "at lambda_method(Closure , Stream , Stream , ContextInfo )"
  ],
  "cause":   {
    "errorType": "FileNotFoundException",
    "errorMessage": "'AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604' not found in the deployment package or in the installed Microsoft.NETCore.App.",
    "stackTrace": [
      "at AWSLambda.Internal.Bootstrap.LambdaAssemblyLoadContext.Load(AssemblyName assemblyName)",
      "at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName)",
      "at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)"
    ]
  }
}

AWSSDK.Lambda を参照追加する

対策は容易です。project.jsonAWSSDK.Lambda も追加してください。もちろん AWSSDK.* なパッケージはすでに .NET Core 対応されているので安心です。*7

AWS SDK for .NET Status Update for .NET Core Support | AWS Developer Tools Blog

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0"
    },
    "Amazon.Lambda.Core": "1.0.0*",
    "Amazon.Lambda.Serialization.Json": "1.0.1",
    "Amazon.Lambda.Tools": {
      "type": "build",
      "version": "1.0.0-preview1"
    },
    "Newtonsoft.Json": "9.0.1",
    "AWSSDK.Lambda": "3.3.2.4",
    "LambdaShared": "1.0.0-*"
  },

  "tools": {
    "Amazon.Lambda.Tools": "1.0.0-preview1"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
}
環境変数

今回は、通知先のChatwork RoomIdを決め打ってしまっています。これは環境変数に設定しまいます。

Debug実行対応

ローカルデバッグ、Circle CI でのデバッグ実行において AWS Lambda を呼び出ししているため、環境変数に AWS 認証を設定しておきましょう。

これらが設定されていれば、xUnit で作成した Unit Test も通ります。

Lambda の作成

コードがかけて IAM も用意できたら、Visual Studioや CI でデプロイします。これでUnityCloudBuildNotificationProxy Lambda が生成されます。

テストも通っていればok ですね。

(AWS 側設定) API Gateway の設定

POSTを受けるようにします。

バックエンドは先ほど作成したUnityCloudBuildNotificationProxy Lambda です。

JSON のフォーマット

コンテンツタイプが application/json だった場合に、body : Webhokで送信されたJSON となるように整形します。

整形は、いつも通りIntegration Request > Body Mapping Templates で行います。

パラメータ
Content-Type application/json
Mapping { "body": $input.json("$") }

これでok です。

ビルドテスト

さぁ長くなりました。Unity Cloud Build でビルドしてみると...?

うまく通知されましたね。

Lambda の実行を Cloud Watch Logs で確認しても上手くいっています。

まとめ

Unity Cloud Build は、Unity 開発をするにあたって欠かせない存在になってきています。こういった Webhook のサポートもありどんどん使いやすくなっているのでぜひ活用していくといいですね。

Unity 操作や細かい注意を書いたので長くなりましたが、実はやってる作業はこれまでの AWS Lambda の記事とあまり変わりません。今回のコードも Github にあげておきます。

github.com

*1:AzureFunctions でもほとんど変わりません。楽ちん!

*2:正直、現状CircleCI やVSTSを含めたふつーのSaaS型CIに比べてコナレテいるとは言いが難いかなぁと感じています

*3:SteamVR Plugin を足しただけのモック

*4:VR で今ならAlways Use Latest 5.5 が機能への追随ができるので望ましいと思います。5.6を選択できるようになってほしいですね

*5:Github などでももちろん可能です

*6:Lambda のネスト実行

*7:このあたりAWS .NET チームは昨年から準備を進めて、今年の.NET Core GA -> .NET Core on AWS Lambda にきっちり間に合わせていて素晴らしいです。

2016 年の人気記事ランキングを出してみた

今年もアクセスランキングを Google Analytics から出してくれるサービスで出してみます。

blog.shibayan.jp

目次

ランキング

相変わらず PowerShell な記事がヒットするようです。リアルタイム通信という名の当時のWebにおけるほげもげ記事は現時点で本ブログ最大のブックマークなのでほむり。

順位 記事 公開年
1 PowerShell での文字列出力について考える - tech.guitarrapc.cóm 2014
2 PowerShellの Out-File と Set-Content あるいは Out-File -Append と Add-Content の違い - tech.guitarrapc.cóm 2014
3 PowerShellで日付書式にカスタム書式パターンを指定する - tech.guitarrapc.cóm 2013
4 PowerShellでリモートPCの操作を行うに為にEnable-PSRemotingをするための準備 - tech.guitarrapc.cóm 2013
5 そろそろ PowerShell の一次配列の罠と回避について一言いっておくか - tech.guitarrapc.cóm 2015
6 PowerShell のモジュール詳解とモジュールへのコマンドレット配置手法を考える - tech.guitarrapc.cóm 2013
7 リアルタイム通信で利用されるプロトコルと手法 - tech.guitarrapc.cóm 2015
8 PowerShell でディレクトリ構造を保ったまま特定のファイルをコピーする(1) - tech.guitarrapc.cóm 2014
9 PowerShell の コマンドレット例外を取得する - tech.guitarrapc.cóm 2013
10 PowerShellで文字列の比較をする際のTips - tech.guitarrapc.cóm 2013

アクセス数的には、2015年よりも 100,000 余り伸びています。しかし2016年の記事が一件もヒットしないのはむむぅ。

2016年の記事に絞ったところ、はてなブックマークに準じたようなそうじゃないような... なんとなくそうだろうなぁという順番になりました。とりあえず意図通り記事の変遷につながっているようなので、引き続きこの感じで。

順位 記事 公開 2016年公開記事におけるPV割合
1 https://tech.guitarrapc.com//entry/2016/04/25/060920 2016/04/25 17.18%
2 https://tech.guitarrapc.com//entry/2016/03/26/070012 2016/03/26 13.12%
3 https://tech.guitarrapc.com//entry/2016/01/07/100248 2016/01/07 6.29%
4 https://tech.guitarrapc.com//entry/2016/04/11/070745 2016/04/11 5.35%
5 https://tech.guitarrapc.com//entry/2016/05/15/105054 2016/05/15 4.53%
6 https://tech.guitarrapc.com//entry/2016/08/24/044850 2016/08/24 4.26%
7 https://tech.guitarrapc.com//entry/2016/04/14/135520 2016/04/14 3.98%
8 https://tech.guitarrapc.com//entry/2016/03/15/011802 2016/03/15 3.64%
9 https://tech.guitarrapc.com//entry/2016/08/29/092502 2016/08/29 3.49%
10 https://tech.guitarrapc.com//entry/2016/05/28/173049 2016/05/28 3.36%

まとめ

幾分思うところもありますが、少しでも皆様のお役に立っている側面があるなら嬉しい限りです。

某なんとか審査のために、正確なPVをとりたいため はてなブログPro や Google Analytics をみるのですが、やはり Google Analytics のほうが分析が楽でいいですねぇ。