Masteries

技術的なことや仕事に関することを書いていきます.

SocketIO::Emitterとsocket.io-redisに関する最近の状況

これは「Perl5 Advent Calendar」の23日目の記事... 記事です. まず最初に, 更新が23日の72時頃になってしまったことをお詫び致します*1. やっていけませんでした...

今日のお題

というわけで改めてやっていきたいと思います. 今日は, 以前「SocketIO::EmitterがCPANで公開されました!」という記事で, PerlのSocketIO::EmitterモジュールとNode.jsのsocket.io-redisパッケージのバージョンは気をつける必要があるというお話をしたのですが, それの続報(?)についてやっていこうと思います.

papix.hatenablog.com

ふりかえり

これまでの問題をさっくりまとめると, 以下のようになります.

  • Node.jsのsocket.io-redisが利用しているMessagePackのライブラリは, 古い仕様に基づいて実装されている
  • そのため, PerlのSocketIO::Emitterを利用する場合, (古い仕様に基づいて実装されている)Data::MessagePackの0.49以前を利用しなければならなかった

...という感じです. Data::MessagePackをSocket.ioのEmitのみに利用するのであれば, Data::MessagePackの0.49以前を利用するようにcpanfileなどで指定しておけば良いのですが, 言うまでもなくSocket.io以外で新しい仕様に基づいて実装されているData::MessagePackの0.50以上を使いたい! という場合に併用できない, という問題点がありました.

最近の状況

socket.io-redisは, 12月8日にmasterブランチへマージされたPull Requestで, msgpack-liteを利用するようになりました.

github.com

このNode.js用のMessagePackのパッケージは, 新しい仕様に基づいてMessagePackを処理するようになっています(ちなみに, このパッケージは古い仕様のMessagePackにも対応しているみたいです). これで, めでたくData::MessagePackの0.50以上でSocketIO::Emitterを使えるようになる... のですが, 残念ながらこのPull Requestが反映されたバージョンは, まだリリースされていません.

もし, どうしてもsocket.io-redisとSocketIO::Emitterを使いながら, Data::MessagePackの0.50以上を利用したい場合, 当面はpackage.jsonでsocket.io-redisのGitHubのリポジトリを使うように指定してあげると良さそうです:

qiita.com

しばらくしたら, 恐らくmsgpack-liteを利用するsocket.io-redisがリリースされると思われます. そうなると, SocketIO::Emitter + Data::MessagePack 0.49以下の環境からうまくEmitできなくなりますので, 上記で紹介したようにsocket.io-redisの最新版を利用するようにするか, 或いはsocket.io-redisのバージョンを現状の最新版である2.0.1に固定しておいた方が良さそうです.

まとめ

SocketIO::Emitterとsocket.io-redisを利用する際の注意点について, 最新の情報をお伝えしました. SocketIO::Emitterや, Node.jsのsocket.io系のパッケージを利用すれば, 非同期双方向通信なアプリケーションが簡単に作れますので, この機会に(?)皆さんも是非試してみては如何でしょうか!

スペシャルサンクス

*1:引っ越しとかしていました...

株式会社ガイアックスを退職します

いろいろありまして, 2014年4月から2年と9ヶ月程働いていたガイアックスを退職することになりました. 一応, 本日が最終出社日*1となっていて, 暫くの間有給消化になります.

どうして辞めるの?

いろいろと, 今回の転職に至る経緯とか, ガイアックスでの思い出などを書いていたのですが, 分量が増えてきて止まらない感じになってきたので, また別エントリで, じっくり綴らせて頂ければと思っています...

次はどうするの?

次の会社, すなわち転職先は既に決まっていて, 2月頃から働き始める予定です. これに伴い渋谷区への引っ越しなどもやっていて, 退職に向けた手続きなども含めて, 非常に慌ただしい年末を過ごしています...

最後に...

だいぶさっくりではありますが, いつもお世話になっている皆様への第一報ということで, よろしくお願いします.

なお, こちらいつものやつです. ご査収下さい: https://www.amazon.co.jp/registry/wishlist/207LWIVX9Y04Q

*1:正確に言えば引き継ぎやPCの返却などで1月もちまちまと出社するのですが, 大規模な有給消化が来週月曜日から始まり, 年内最終出社が今日になったので, 今日を最終出社日としています.

Mackerelを使って踏み台サーバを更に便利にしてみた話

この記事は, Mackerel Advent Calendar 2016の19日目の記事です.

「踏み台サーバ」とMackerel

以前, 「サーバにログインした時に任意のメッセージを表示する 〜Mackerelで管理しているホスト一覧を出す〜」という記事を書いたことがあります.

papix.hatenablog.com

この記事では, いわゆる「踏み台サーバ」にログインしたタイミングで, MackerelのAPIを使って「踏み台サーバ」に紐づくサービスのホスト一覧を取得して, 次のように表示してあげる便利! というTips? を紹介しました.

-----------------------------------------------------------------
    My Service Host Information
-----------------------------------------------------------------
App
        10.0.xxx.xxx (instance-size) ... working
        10.0.xxx.xxx (instance-size) ... working
                      :
                      :
-----------------------------------------------------------------

今回もまたまた小さいTipsなのですが, これを改良(?)する機会があったので, そのお話をしたいと思います.

IPアドレスをちまちま入力するのは面倒じゃないですか?

...と思った訳です.

ここから, 実際に各サーバに接続しようとすると, ssh 10.0.xxx.xxxのように, 手動でIPアドレスを入力していく必要があります. ちょっと面倒ですし, 例えば10.0.123.456とするべきところを, 10.0.124.456とタイポしてしまうことも多々ありました.

補完を効かせたい!

...と思うのは, 自然なことだと思います.

やり方はいろいろありますが, 今回は「任意のサーバに接続するコマンド」を用意して, これを補完させるというアプローチを取りました.

具体的には, 「ホストの一覧を表示」するスクリプトの中で, ホストごとに次のようなファイルを生成するようにします.

#!/bin/sh
ssh [user]@[ip address]

これを, 例えば/usr/local/bin/ssh/[ip address]というファイルに設置して, 実行権限を与えた後, /usr/local/bin/sshにパスを通せば良いでしょう.

なお, Mackerelで管理しているサーバが入れ替わるなどしてIPアドレスが使われなくなる事は多々あると思うので, 「ホストの一覧を表示」するスクリプトが実行される度に/usr/local/bin/sshの中に存在するファイルを全て削除して, 都度生成しなおすようにしています.

結果

こうすることによって, 例えば「踏み台サーバ」から10.0.123.456というホストに接続したいのであれば, 10.0.123.456とタイプするだけで接続することができるようになりました.

更に, 10.0.辺りまで入力して「TAB」キーを押せば, よしなに補完してくれるので, 「踏み台サーバ」から目的のサーバに移動するのが非常に簡単になりました.

非常に細かいTipsではあるのですが, チームメイトからの評判? は非常に良くて, 便利だと思ったので紹介させて頂いた次第です.

僕達の日常に這い寄るGet Wild

この記事は, Get Wild Advent Calendar 2016の13日目の記事です.

はじめに

皆さんGet Wildしていますか? 最近はどっちかというとBE MY BABYしている機会が多いのですが, とりあえずチープなスリルに身を任せながらGet Wildしていきましょう.

日常に這い寄るGet Wild

さて, 勢いでGet Wild Advent Calendarに応募してしまい, どういったネタ記事を送り出すべきかと, ひとりでは解けない愛のパズルを抱きながら考えていました.

前日になってもアイデアが浮かばず, 明日におびえていた訳ですが, その最中私は気づいてしまいました.

...すでに私達の身の回りには, Get Wildが, 音もなく, 静かに這い寄ってきていたということに.

どういうことか?

例えば, ここにピックアップしたのは, 今自分が携わっている某サービスのインフラ〜ミドルウェアレイヤーで使われているツールの一覧です.

  • GitHub
  • AWS
    • EC2
    • ElastiCache (Redis)
    • ElasticSearch
    • RDS (MySQL)
    • S3
    • Route53
  • Linux (Ubuntu)
  • Terraform
  • Itamae
  • Packer
  • Concourse CI
    • Docker
  • Mackerel
  • WordPress

GitHubでリポジトリを管理して, AWS上にサービスを構築. AWSはTerraformで構築の自動化を試みています.

サービスはEC2上で動き, OSはLinux(といっても, Amazon LinuxではなくUbuntu)を採用しました. みんなだいすきInnoDBを使いたいので, RDSのMySQLを採用し, 必要に応じてRedisやElasticSearchも導入しています.

アプリケーションが動くインスタンスはAMIをPackerで構築してそこから起動しますが, 「踏み台サーバー」などのミュータブルなインスタンスについてはItamaeで構築します.

デプロイの自動化については, Concourse CIを採用しています. Concourse CIでは, 各ジョブがDockerのコンテナ上で動くので, CIサーバに直接デプロイなどに必要なミドルウェアやツールを導入する必要がなく, そういったツールが入ったDockerのイメージを作ってあげればOKなので, 非常にわかりやすいです.

また, インフラの監視にはMackerelを, 公式サイトのためにWordPressを使っています.

なるほどなるほど, 「GitHub」... 「EC2」... 「Terraform」... 「WordPress」... 「Itamae」... 「Linux」... 「Docker」... ハッ!?

G E T  W I L D

そう, 私達のサービスは, 知らないうちにGet Wildが紛れ込んでいたのです...!

あなたの側にもGet Wild

皆さんも, 改めて開発しているサービスに注目してみてください.

もしかすると, 皆さんのサービスも, 既に, Get Wildが...