べにやまぶろぐ

技術寄りの話を書くつもり

GitLab 7.5.3 でマージリクエスト時のコミットログが大量に表示される問題が解消

Git/GitHub/GitLab

GitLab 7系に上げてから出ていた表記の問題、下記の stackoverflow にあるようにブランチ比較に使われている git ラッパーの Rugged のバグに起因するものでした。マージリクエストを作成するとブランチ間の差分コミットが全履歴分？出てしまって画面で diff を表示できない、そもそもブラクラになってしまうというものでした。

これも stackoverflow に書かれているように Gemfile.lock の Rugged のバージョンを 0.21.2 に手で修正して bundle install をやり直すことで回避できていましたが、ようやく最新の 7.5.3 で正式に解消されたようです。

GitLab 7.5.3 Release | GitLab

GitLab 7.5.3 updates Rugged to 0.21.2 to solve issues with 'finding too many commits'. This issue could cause the PostReceive job triggered by a git push to take a very long time and consume a lot of memory.

Docker Hub と GitHub を連携させて、SparkR を RStudio から呼び出せるコンテナイメージを公開してみた

Docker Apache Spark Git/GitHub/GitLab

バージョン : Spark 1.1.0

長ったらしい題名ですがそのまんまです。以前書いた お手軽に Spark と SparkR を触るための Dockerfile 書いてみました。 - べにやまぶろぐ で Apache Spark と SparkR をセットアップして RStudio とつなげてみたもののそれからメンテナンスできてなかったので Spark も 1.1.0 になったことだしと思って更新しました。

こちらが GitHub です。

ところが Spark のビルドってすごい時間かかるのでもういい加減構築済みのイメージ提供しましょう、ということで今回初めて Docker Hub に登録してみました。

こちらは Docker Hub。

Docker Hub ですが、GitHub に Dockerfile 載せておけば push が走るたびに docker build を自動的に流せる Automated build が便利すぎます。詳しい解説は Docker Hubの使い方とGitHubからのDockerイメージ自動ビルド：いまさら聞けないDocker入門（終）（1/2 ページ） - ＠IT にあるので割愛しますが、ローカル PC をひいひい言わせなくてもクラウドでビルドして出来上がったら勝手にリポジトリに登録して docker pull とかすれば誰でも使える状態にしてくれます。

f:id:beniyama:20141202011403p:plain

Docker Hub へは GitHub のアカウントでログインできますし、GitHub の README.md も勝手に Docker Hub のページに同期してくれるので、いちいち同じ説明を書く必要がありません。よく考えられてるなぁと思います。

README にも書きましたが、

$ docker pull beniyama/sparkr-docker
$ docker run -d -p <YOUR PORT>:8787 -t beniyama/sparkr-docker

などとして

$ boot2docker ip
The VM's Host only interface IP address is: 192.168.xxx.xxx

で boot2docker vm の IP を確認、そして http://192.168.xxx.xxx:<YOUR PORT>にアクセスすれば SparkR 梱包済みの RStudio をすぐ使えますので是非お試しいただければと思います（初期アカウントは rstudio/rstudio）。

↓ 昔の記事

Intel Edison Breakout Board Kit で遊んでみる（その２）

Edison Maker

Intel Edison Breakout Board Kit で遊んでみる（その１） - べにやまぶろぐ の続きです。

本当は今頃センサつなげているはずだったんですが GPIO 周りの調査していたり、そもそも Breakout Board Kit には Analog Input がないらしい（Intel Edison Board for Arduino にはある） というところでもたついているので今回は乾電池で Edison 動くか実験してお茶を濁そうと思います。

参考にするのはこちらのドキュメント。

Hardware guide によれば

The left pin (the square one) on J2 is +V battery; the right pin is ground.

とあり、かつスケマには BAT1 / BAT2 とあるので J2 を使ってみます。

今回、横着して手で接触させて動作確認したいだけなのでちゃんと起動しているかは J3 側の USB を母艦と接続して screen でコンソールを確認します。

ちなみに J3 は

J3 is a micro USB FTDI serial-to-USB converter. The Linux console will output serial stream to this USB connector.

というようにシリアルのインタフェースを提供してくれます（前回つないだのはもう一方の J16 でした）

f:id:beniyama:20141126012541j:plain

USB 接続後、母艦の Mac 側で

screen /dev/cu.usbserial-AJ035HM1 115200 -L

などと実行します（cu.usbserial- の後は違う文字列になっているかもしれません）。

その上で、今回とりあえず手元にあった単三のエネループ２本直列につないで 2.5V 弱供給してくれる乾電池パックの線を J2 に接触させてみます。

f:id:beniyama:20141126010716j:plain

LED がチカチカし始め、コンソールには

f:id:beniyama:20141126020607p:plain

などと流れ始めて boot の予感。

f:id:beniyama:20141126020641p:plain

なんか Battery Over heat exception とか出てる...

f:id:beniyama:20141126020720p:plain

途中なんかこけてるけどとりあえずログインまでたどり着きました。

一応 boot はしましたが、とても雑なのでもう少しちゃんと配線してログ見てってとこは引き続きやっていこうと思います。特に 2.3.1 Boot voltage selection – DCIN signal の辺り読んでいると最低限 boot しただけっぽいので。もう少し読み込む必要あり。

ちなみに J2 は

J2 is the battery connector. If you want to power the breakout board with a rechargeable lithium-ion battery, attach it to J2. (Refer to Figure 2 for battery polarity.) When you attach a rechargeable lithium-ion battery, the breakout board will recharge the battery whenever power is applied via J21 or J22, or via J3 (when the board is attached to a USB host).

などとあって USB 給電からの充電なんかもできるそうです。こちらも併せて試してみたいところ。

↓ 前回の記事です

AJITO(アジト）×キャリア・ラボラトリー アドテク勉強会（11月21日開催）に参加してきました #ajiting

セミナー・勉強会 アドテク DevOps Scala

VOYAGE さんの AJITO で開催されている勉強会 http://careerlaboratory.jp/archives/656 に参加してきました。

登壇者との距離が非常に近くて、いろいろと貴重なお話を聞かせていただきました。メモの公開許可を頂きましたので、おそらく差し支えないであろう範囲で書かせていただきます。

「SSP：FluctでのBlue-Green Deproyment事例」 (@_nishigori さん)
  • @_nishigori さん : adingo の DevOps エンジニア
  • Fluct SSP で blue green deployment を実現している
  • AWS の Route53 を使ってバランシング対象を切り替えている
    • ELB & autoscaling
    • EC2 instance & puppet
    • service in (green)
    • service out (blue)
  • 最初から設計していたわけではなく、結果的にそうなった
    • impression 増大でサーバに同梱している CookieSync は他に逃したかった
    • オンプレを徐々に AWS に移行した
    • オートスケーリングをスケジューリングしている
    • サービスインしていないほうで ServerConfiguration もデプロイも全て試せた
    • AWS での Management Console 上での操作が辛かった
    • ELB の Pre-warming には事前に電話での申請が必要だった
    • AWS-Cli は JSON ばかりだった
    • Elastic beanstalk もあるがそこまで AWS にロックされたくなかった
    • 突然 EC2 instance が reboot したりする
    • 息を吐くようにインスタンスを上げ下げしたい
  • aws 用デプロイツールを作った
    • YAML で設定を書ける
    • ELB なんちゃって warm up ができる(徐徐に負荷を上げる)
  • 今後は AMI にして構築済みのイメージをデプロイするようにしたい
  • その先に RDB などはつながっていない
    • DB は blue green にするコスト見合っていない
  • 切り替えは 20分以上かかる
  • テストについて
    • cookie を焼けたかのテストはインスタンス上げたときにテストしていて、落ちたらサービスインできないようになっている
    • テストをした環境が本番になるといいなという気持ち
「Scalaのアドテク事例」(@katzchang さん)
  • Zucks Ad Network : スマホ向け課金型広告ネットワーク
    • Scala : 広告配信サーバ
    • PHP : 管理画面
    • Scheme (Gauche) : バッチ処理
      • fluentd と連携させて使っている
      • Scala より質問が少ないくらいなじみやすい (SICP の本の読書会をやっている)
  • Fluentd, Tomcat, AWS, GitHub, New Relic（モニタリング）...
  • Scala : 少量で高いスループットを安定して処理する必要がある
  • 最初は Java で書いていた
    • 広告配信はフィルタの連続 : Function, Predicate クラスを独自実装
    • 不具合なくしたい == ぬるぽなくしたい Option クラスを独自実装
      • Scala は Option 便利
    • IDE がしっかりしていてリファクタリングができる
      • IDE は IntelliJ
  • Scala のつらくないところ
    • プログラマの確保、みんな書ける
    • GC 問題、たまに応答ないけれど全体としては稼げてるのでとりあえず問題ない（たまにフルGCかかるけど全体的には商売で稼げてる、許容できないとしたらそもそも JVM 向いてない）
  • つらいところ
    • コンパイル遅い、sbt 複雑すぎる（マルチプロジェクト構成の資料がない）
      • 普段は立ち上げっぱなしでコマンド打ったりしている
    • パフォーマンスの予測がつかないところがある
    • リリース後５日感がサーバ台数増やしてチューニングの時間を稼いでいた
    • 直接 DB につながず、内部にハッシュマップを持たせて掲載しているメディアの情報等を引いていた
      • 恐ろしく遅かった
      • ベースになる JSON のマッパーの実装が悪かった疑惑（罠）
    • Tuple で ((int),(int)) のハッシュマップ使っていたりしたとき New Relic で見たときサーバリソースの３割使っていたりした
      • Hash 値計算に時間がかかってた
      • Case クラスをキーにすることで解消、全体のスループットが２割くらい上がった
        • pre compile されたハッシュコードを持っている？？
        • 3,000 件の get に 50ms かかっていた
      • Scala のバージョン 2.1 くらい
    • toList とか気軽に使わない
      • 数メガから数百メガのファイルを読まないといけないとき全行一気にメモリに全部載せてしまっていたので、一行一行処理してやるようにした
      • Java の BufferedStream だとあまり問題にならないだろう
  • Tomcat => とりあえず servlet でもそれなりのパフォーマンスは出る
  • ID をもらって広告をハッシュマップで返す
  • New Relic 見るとどのプロセスがリソース使用しているか一目で見える

参考)

Intel Edison Breakout Board Kit で遊んでみる（その１）

Edison Maker

薄々気になってた Intel Edison を入手したので遊んでみます。

とはいえ参考にさせていただいた SDカードサイズの極小コンピューター、「Intel Edison」を手に入れた – PSYENCE:MEDIA にもっと詳しく書いてあるのでほぼ備忘録です。

今回は Amazon からポチッと。

Intel Edison Breakout Board Kit
Intel Edison Breakout Board Kit
posted with amazlet at 14.11.17
Intel
売り上げランキング: 37,402
Amazon.co.jpで詳細を見る

Edison はそのサイズもあって開発にはピッチサイズ変換用の拡張用ボードが必要です。Intel 謹製の拡張用ボードには Breakout Board と Arduino 互換のものがあるようですが（2014/11/17 現在）、とりあえず在庫があったので Breakout Board を購入してみました。Arduino 互換の方が数あるシールドと簡単につなげそうではあります。

梱包を解いたのがこれ。

f:id:beniyama:20141117235349p:plain

USB ケーブルは付属していないので注意が必要です。梱包物は Edison と拡張用ボード、それとマウントして止めるための金具が付いているだけ。USB ケーブルの口は二つありますが、片方は OTG でもう片方はシリアル通信用ということでとりあえずは一本でも大丈夫。

f:id:beniyama:20141117235359p:plain

箱も小さいです。

最初、さーてどうしよっかと公式サイト見て回ってたんですが https://communities.intel.com/docs/DOC-23148 によれば

Note: If you’re using Intel® Edison for the first time, we recommend starting with the Intel® Edison kit for Arduino* expansion board. The following Intel® Edison Getting Started Guide has been written for use with the Arduino expansion board (Edison Arduino expansion board hardware guide_331191-002.pdf). If you are using Intel® Edison for the first time with a different expansion board, please consult documentation provided by the supplier of that expansion board.

とかあって早速 Breakout Board Kit にしたことを後悔しそうになります。

気を取り直して IntelEdisonStartGeneric – スイッチサイエンス を参考にしてまず HoRNDIS をインストールします。*1

その次に USB コネクタを接続して母艦の Mac に接続。一本で繋ぐ場合は "Intel Edison" の文字から見て右下の口につなぎます（ここで右上につないでも電源供給されないのでダメです）。電源供給されると緑色の LED が点灯します。

f:id:beniyama:20141118002812p:plain

"Multifunction Composite Gadget" というインタフェースが現れるのでそこの IP を 192.168.2.2 などとします。

f:id:beniyama:20141118003216p:plain

SSH でパスワードなしの root でログインできます。/etc/version を cat すると焼かれているイメージのバージョンがわかります。

$ ssh root@192.168.2.15
root@edison:~# ls
otp.bin
root@edison:~# cat /etc/version 
edison-weekly_build_56_2014-08-20_15-54-05

ここで Edison のイメージを更新します。https://communities.intel.com/docs/DOC-23242 から最新のビルド済みイメージ（Edison Yocto complete image）をダウンロード。

https://communities.intel.com/docs/DOC-23242

zip を展開して、中身をマウントされている Edison フォルダにコピーします。

f:id:beniyama:20141118004336p:plain

その後 Edison のシェルに戻り

root@edison:~# reboot ota

とすると新しいイメージが焼かれます。しばらく時間がかかりますがここで電源供給が止まったりすると起動しなくなったりする気がするのでしばし辛抱。

自分の場合はネットワークインタフェースもリセットされてしまったのでもう一回プライベート IP を振ってやって known_hosts に一度登録されていた鍵を削除して SSH でつなぎ直しました。

root@edison:~# cat /etc/version 
edison-rel1-maint-weekly_build_16_2014-10-14_14-56-19

アップデートされていることを確認。

その後は

root@edison:~# configure_edison --setup

でホスト名を設定したり Wifi の設定をするだけで

f:id:beniyama:20141118004509p:plain

のようにブラウザからアクセスできるようになります。簡単！

次はなんかセンサーをくっつけてみようと思います。

参考)

*1:Yosemite だったのと最初つなぐとこ間違えてて上手く認識されなかったのでサイトのガイドに従って NetworkInterfaces.plist と preferences.plist を削除したりしましたが必要なかった気もします

『GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望』を公開しました。

DevOps Docker 発表資料・スライド 継続的デリバリー

先日、10/30 にリリースされました http://pr.gmopdmp.jp/ の開発に当たって取り組んできた DevOps のプラクティスなどについてまとめた資料を Slideshare で公開しました。

資料中にありますようにまだまだ発展途上で今後も取り組んでいきたいこともかなりありますので、技術ネタを交えて継続的に更新していければと思います。

http のリクエストが勝手に https にリダイレクトされるときは Strict-Transport-Security を疑おう

Nginx/Apache

mysite.jp というサイトを運用していて、新たに help.mysite.jp みたいな別サイトをサブドメイン切ってかつ別の Web サーバーで用意したとします。

このサイトはヘルプページがメインなので高額な SSL 証明書をとらず http で良しとしていた…つもりが http://help.mysite.jp へのリクエストが何故か勝手に https://help.mysite.jp にリダイレクトされてしまい挙げ句の果てに証明書のエラーが出てアクセスできない、なんてことがありました。

最初は help.mysite.jp に問題があると思って色々調べていたんですが、実は問題のあったのは mysite.jp の方。mysite.jp はログイン前提のサイトだったのでこんなヘッダを設定していました。

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

この Strict-Transport-Security、Strict-Transport-Security - HTTP | MDN によれば

HTTP Strict Transport Security (よく HSTS と略されます) は、Web サイトがブラウザに対して、HTTP の代わりに HTTPS を用いて通信を行うように伝達することができるセキュリティ機能です。

ということでどうせ https しか許可してないしということで設定していたのですが、このヘッダに includeSubDomains が付いていたために、後から作った help.mysite.jp にも同じポリシーが適用されてしまっていたことが https リダイレクトの原因でした。

ここでのポイントは mysite.jp と help.mysite.jp が違うWeb サーバーで運用されていて、かつ Strict-Transport-Security の設定は mysite.jp にしかされていなかったという点です。

何が起きているかというと、例えばあるユーザーが mysite.jp にアクセスしたとき（１）にサブドメインも対象にした Strict-Transport-Security 入りヘッダが付いたレスポンスを受けます（２）。

f:id:beniyama:20141108224904j:plain

このとき、ブラウザは内部に持っている HSTS 対象のドメインリストに mysite.jp を追加します（３）。ブラウザはこのように HSTS のポリシーを持っているドメインをキャッシュして、次につなぎにいく際は内部的にリクエストを https に書き換えます。これは、内部で処理を行うことで極力（脆弱な） http でつなぎにいくのを避ける目的があります。

今回のケースでは includeSubDomains でサブドメインも対象になっていましたので、次に HSTS ヘッダ無しで運用されている http://help.mysite.jp にアクセスしようとした際もブラウザ内のキャッシュ（HSTS リスト）が効いて https://help.mysite.jp に向いてしまうのでした（４）。

ユーザーが mysite.jp を訪れずに直接 help.mysite.jp にアクセスした場合は当然 HSTS 対象のドメインとして認識されていませんから問題なく http でサイトを表示することが可能です。

結局はブラウザ側でなされている脆弱性対応なのですが、最初に接続しにいって HSTS ポリシーを受け取るまではドメインが https を強制しているかわからず http でのやりとりになる可能性があります。また HSTS には max-age というオプションがありブラウザが HSTS ポリシーをキャッシュする期間を設定することができるのですが、あまり頻繁にキャッシュアウトするような短い期間を設定してしまうとその度に http でつなぎにいってしまう可能性がありますので、十分長い期間を設定することが推奨されているようです（max-age はサイトにアクセスするたびに更新され期限は延びます）。

今回の問題は、ブラウザが持つ HSTS リストに依るのでユーザー毎に挙動が違う、また外部サイト（この場合は mysite.jp ）の設定に影響を受けていたという点でちょっと厄介だったかなと思います。

教訓としては、

Strict-Transport-Security を includeSubDomains 付きで設定するときは既存のサブドメイン全てのセキュリティポリシーを確認しましょう

というのと、

新たにサブドメイン切るときもそのルートドメインで includeSubDomains 付き Strict-Transport-Security を設定していないか確認しましょう

ということでしょうか。

ちなみに、Chrome などでは preloaded list として予めいくつかのドメインを HSTS リストに持っているようです。またユーザーが自分でドメインを HSTS リストに追加することもできますが、長くなってしまったのでそれはブラウザ間の挙動の違いと一緒にまた次回書こうと思います。

参考)