冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

Docker for Macのホストについて誤解を修正したのでメモ

rocker/rstudioを動かしていた時に、DockerfileのVOLUME指定がどこにマウントされてるのかなあ、と疑問になって誤解していたのに気付きました。

普通に立ち上げたrstudioのコンテナに対して docker inspect 叩くとマウントはこんな感じになります(抜粋)。

        "Mounts": [
            {
                "Name": "03ea6111736ad40a69f279c6cba05b5ebfc50c0454e612521766b019b5efbb0e",
                "Source": "/var/lib/docker/volumes/03ea6111736ad40a69f279c6cba05b5ebfc50c0454e612521766b019b5efbb0e/_data",
                "Destination": "/home/rstudio",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
        ],

で、ローカルの /var/lib/docker/volumes/ とかないんですね。

Docker for Macのホストは(厳密には)ローカルマシンではない

ちゃんとリリースノート読めよ、という感じなのですが、docker-machineでも管理下のホストがないことになってるし、linuxで使うときと同じようにネイティブで動くホストだと思ってたんですよね。だからVOLUMEでマウントされるのもローカルにそのままパスがあるところなのかと思っていました。

Docker for MacはxhyveというOS Xのネイティブハイパーバイザーでlinuxを仮想化したホストで動いています。とりあえずVirtualBoxからは脱却してますが、完全にネイティブではなく一つ仮想環境が挟まってる状態は同じなんですね。ここ、完全にネイティブだと勘違いしていました。私のちょっと時代遅れのマシンでもある程度サクサク動いてくれるので、パフォーマンスは向上してるとは思います。

paiza.hatenablog.com

このブログを参考にしてホスト環境にアクセスしてみたところ、VOLUMEでマウントされているディレクトリを確認できました。

ちなみに、KitematicではNo folder扱いです。これは、ホストの環境はあくまで一時的なものだからな?ということなのでしょうかね。永続化するデータはちゃんとコンテナ動かす時にマウントしておきましょう、という話。

デブサミ関西に行ってきました

もうすっかり恒例になりましたね。昼飯難民になりやすい場所も時期も。神戸という距離感も参加しやすさという意味ではありがたいところ。

参加したセッション

  • キーノート(鈴木さん)
  • 【A1】正しいものを正しく作る(市谷さん)
  • 【B2】企業向けクラウドサービスの開発・運用(三苫さん)
  • 【B3】ビジネスにおける機械学習の現場(木虎さん)
  • 【B5】カイゼンの基本(吉羽さん)

キーノートは、駐車場探しに手間取ってしまったため15分ほど遅れて入りました。

【B5】はちょっと帰りの時間と体力的に嫌な予感がしたのと、自分の活動を資料と照らし合わせて比較ができそうなのを最初の15分ほどで確認して退出しています。

セッション資料

私が参加していないセッション資料も含めてまとめてくださっている方がいますね。

デブサミ関西2016 スライドまとめ84zume.wordpress.com

感想

最近はこういう場で「遅れないようにしないと」とか「どこか別の世界線の話」と思うより、「ああ、こんなやり方があるんだ」と比較しながら聴くことができるようになっているのを感じます。まあ、やりたいことがやれてきて悩みどころが追いついているというか、今の現場はそういう意味では幸せです。

各セッションごとの感想を軽めに。

キーノート

これ、大都会でやるとポカーン枠って言われるやつや。。。

ちなみに、ブルーグリーンデプロイメントって名前知ったのはこのセッションよりも少し前、どんなデプロイメントかはこのセッションで正しく把握したんですが、MallNaviでは似たような取り組みをしてました。だって、シフト勤務せずにダウンタイム設けずにリリースしたかったんですもの。ElasticBeanstalkさまさま。

とりあえず、自分の開発/運用の頭が2011年以降にはあるということで少しホッとはしました。MSAはとりあえず概要をおさらいくらいはしておきたいですね。

正しいものを正しく作る

これはまあ、今やっていることの課題を共有するというか、考えを整理するために聴いています。仕事面ではギルドワークスさんはだいぶ参考にさせてもらっているので。特にBtoCサービスのオーナーやっているとですね、オーナーもいつまでたっても不安なんですよ。これからも問いに関しては真摯であろうと思いました。

それにしても、早口だった。。。

企業向けクラウドサービスの開発・運用

そもそも資料に載ってる全部がセッションで収まりきらないこと前提という。。。パターンっぽくまとめていただいていたので、資料公開を待ちましょう。

基盤で解決できるところもあり、力技しかないところもあり、ではあるのですが課題はやはりどこも共通していると思います。許容されるレベルが現場によっては異なるくらいかなあ。自分たちの現場はどういう解決、アプローチをしているかを比較しながら聴けたので良かったです。「ゴールが未設定のチューニングタスク」は反省しました。

ビジネスにおける機械学習の現場

これも事例が収まりませんでしたね。本編が盛りだくさんでした。

ちょうど、そろそろデータ分析自体は自分のスキルとして強化しないといけないな、と思い始めていて、買うつもりなかった本なんかも買ってしまっているわけです。

完全に「お前何やりたいんだ」な領域に足突っ込んでる気はしますが、人数少ないですからレベルが低くても誰かが兼務するしかないですよね。本読んでからおさらいしたほうがいい内容でした。

カイゼンの基本

予想通りといえば予想通りな内容。そのレベルが高いところにある、という感じで。

とりあえずバリューストリームマップについてはちゃんと押さえていなかったので、干し芋に入れておきました。 そろそろさんじゅうきゅうさいなので、皆様からの 投げ込み をお待ちしています。 春の大カイゼン運動とか、某社の某取り組みを彷彿とさせて素敵ですね(棒。

おまけ

今回は、ちょっと車で行くのが現実的かどうか試してみました。

行きはバイパスの有料区間を積極的に使って3h、焦ったのはむしろ駐車場探しの方でした。細かい位置関係などはやはり行ってみないとわかりませんし。

ひどかったのは帰りで、なるべく有料区間を使わずにと思って帰ってみたらなんと5hも。渋滞と信号の間の悪さのコンボが効いた感じですね。

まあ、二人以上だったらバスよりも安くは済みそう。

後、珈琲博物館に嫁と行きたいです。

Embulkで検証中に引っかかったことメモ

前回、こんな感じでRe:dashよりも先にやることがあるだろう、と気づいたわけです。

mao-instantlife.hatenablog.com

というわけでEmbulkで各種データソースの読み込みから始めています。

Embulkとは?

バルクデータローダーです。inputとoutputの形式が各種プラグインで提供されていて *1 、対応可能なストレージの種類が多いのが特長です。

他にも公式サイトのアピールとしては、

などありますが、後者二つはまだ試していません。

いつものごとく、公式ドキュメント見れば事足りるインストールやセットアップは割愛。最近はこの辺で試行錯誤して環境による注意事項書かなきゃいけないようなツールが減ってきましたね、いいことです。

覚えておきたいサブコマンド

  • example
  • guess
  • preview
  • run
  • gem
  • mkbundle

プラグインはグローバルなインストールだけではなくて、プロジェクトごとにGemfileつくってバンドルすることもできるようですね。実行環境をテキストで管理できるのは、作る上では嬉しいことです。

exampleはその名の通り、とりあえずローカル実行可能なデモ用の設定ファイルをつくってくれます。試すのにもデータソース作らないといけないの面倒臭いとかそういうニーズがあるんでしょうね、きっと。

guessが入力ファイルフォーマットの自動で、推測した結果を完全な設定ファイルにして出力してくれます(基本は標準出力?)。が、Elasticsearch用のものなどプラグインによっては未対応のものもあるので、全面的に頼れるわけではないようです。

見つけたプラグイン

MySQLのGEOMETRYタイプ問題

Unsupportedですよ、と。

それはそれでいいんですが、エラーメッセージに column_optionstype: string を追加しろと言ってる割には追加してもエラーで変わらず。エラーメッセージの間違いだったようです。

github.com

で、対応するにはクエリでキャストするなりの工夫が必要です。

gist.github.com

まあ、今回は無理してGEOMETRYタイプを使わなくてもいい案件だったので素直に検索対象から外すことにしました。

Google Analytics APIが有効にならない問題

以下の流れで追加したユーザの認証キーを突っ込んで実行してみたんですがね。。。

  • API Managerでサービスアカウント追加
  • API ManagerでAPIの利用を追加
  • Analyticsにユーザ追加して権限を「編集」に設定
Error: forbidden: Google Analytics Reporting API has not been used in project mallnavi-1352 before or it is disabled.

はあ、そうですか。。。APIのリクエストにはカウントされてるし、ちょっとよく分からない。

迂回路は幾つかありそうですし、となると優先順位は全体像を作ることなので、とりあえず放っておくことにして、digdagとEmbulkを組み合わせてみようかと思います。

*1:中はJRubyで動いているらしくgemでインストールします

データ分析環境を作りかけのメモ

一度リリースしたサービスを成長させるんだったら実際の各種データを元に仮説を立てて検証したいところ。アクセスログやアプリケーションデータやGoogle Analyticsの分析データなど、運用時に種々のデータが蓄積されていきます。それぞれでも有用なデータなわけですが、バラバラなままでは活用が難しいこともあります。データは繋いで使ってこそ、意味がある。

というわけで、データ分析環境をどうやって作るか考えて、ここ数週間、要件を書く合間を縫って検証してきた内容と気づきをまとめます。

想定されるデータソース

現状、扱っているデータソース(Analyticsをデータソースと言っちゃうのはあれですが)は以下三つ。

そして、導入を検討しているものとして

  • Neo4j

があります *1

Re:dash

とにかく異なるデータソースをつなぐ環境が欲しい、というわけでRe:dashの導入を検討しました。

redash.io

Re:dashは様々なデータソースをまとめてSQLでクエリを書いてビジュアライズできるソフトウェアです *2

どうも、クエリの結果はRe:dash側にスナップショットをとってる感じがするので、ビューをつくってグラフやなんかでデータを表示させるためのフロントエンドという操作感。Elasticsearchにおけるkibanaのような位置付けで、もっと多くのデータソースに対応できる、というイメージでいいかと思います。

インストールやセットアップなどは公式ドキュメント通りにできたので割愛します。Docker上に環境作れるのはいいですね。

対応していないデータソースへの対応

結構な数のデータソースに対応しているんですが、それでもまだ対応していないものがあります。今回の検証に関わるところだと、

の二つ。

このような場合に検討するのは、

  • 無理くりロードするクエリランナを書く
  • 対応しているデータソースにインポートしてから読み込む

のどちらか、ですね。まず最初は前者を検討してみることにしました。

Pythonクエリランナ

このような未対応データソースへの対応なのかどうかわかりませんが、Pythonクエリランなというのがあります。

Supported Data Sources — Re:dash documentation

なんか、100%セキュアな状態で使ってね、とか怖いこと書いてますが、ローカルでDockerイメージ立ち上げて検証する分には問題ないでしょう。

実際のPythonでのクエリのイメージはここを読んでみてください。

gist.github.com

他のクエリ結果の取得ができるようですね。 ドキュメントに記載がなかったのでソース見てみましたが、提供されているAPIはこの辺っぽいです。

github.com

get_query_resultの引数がidだけなので、パラメータありのクエリは無理?

Neo4jのクエリを書いてみる

注意:結局できなかったのと、やりながら重要なことに気づいてしまったので中途半端に終わります

neo4j.com

Neo4jはPythonのライブラリがあります。というわけで、クエリを書いてみようと思いました。やってみたことは以下。

  • Neo4jのPythonライブラリをインストールしたRe:dashイメージを作る(イメージのビルドとrunは成功)
  • クエリを書いて実行

クエリはこんな感じです。

from neo4j.v1 import GraphDatabase, basic_auth


  driver = GraphDatabase.driver("bolt://localhost", auth=basic_auth("neo4j", "neo4j"))
  session = driver.session()


  session.run("CREATE (a:Person {name:'Arthur', title:'King'})")


  result = session.run("MATCH (n:Person) WHERE n.born >= 1970 RETURN n.name AS name, n.born AS born")
  for record in result:
      print("%s %s" % (record["title"], record["name"]))


  session.close()

これが、どうもライブラリを参照できてないわけです。そもそもPythonクエリランナがどういう参照の仕方をしているかよくわかってないので、pipでインストールするだけでOKなの?とか諸々調査が必要しなきゃいかんかな、と思い始めていたわけですが。。。

ここでふと気づく

で、ここで気づいてしまったわけです。ここまで考えてたことって、本番系を直接データソースとして取り込むやり方の検証なんですよね。何かの拍子にスロークエリ投げてしまったら本番系に影響出してしまう可能性もあるわけです。今更ながらこれはだめじゃん、と。

というわけで、基本的なデータのみ定期的にEmbulkでRedshift突っ込んで読めればいいのでは、ということで今はEmbulkとdigdagの検証に入ってます。この辺が検証終わったらまたRe:dashの検証を再開する予定です。もっと早く気付こう。。。

Embulk — Embulk 0.8 documentation

What’s Digdag? — Digdag 0.8 documentation

*1:導入が決定したわけではないです

*2:一部SQL未対応のデータソースあり。Elasticsearchとか

2016年8月の読書メモ

MPの制約が緩くなったので、何がしたいのかってくらい読んでしまいました。Kindle Unlimitedと図書館が悪い。

今月の読書量

22冊、だと。。。

野田と申します 1巻

スター・レッド

スター・レッド (小学館文庫)

スター・レッド (小学館文庫)

私の恋人

私の恋人

私の恋人

春の呪い

春の呪い: 1 (ZERO-SUMコミックス)

春の呪い: 1 (ZERO-SUMコミックス)

銀河鉄道の夜

ペンギン・ハイウェイ

ペンギン・ハイウェイ (角川文庫)

ペンギン・ハイウェイ (角川文庫)

世界から猫が消えたなら

世界から猫が消えたなら

世界から猫が消えたなら

図解ピケティ入門

世界で戦うプロダクトマネジャーになるための本

ゆらぎの森のシエラ

コンピューターは、むずかしすぎて使えない

コンピュータは、むずかしすぎて使えない!

コンピュータは、むずかしすぎて使えない!

パタリロ 1~2巻

パタリロ!―選集 (1) (白泉社文庫)

パタリロ!―選集 (1) (白泉社文庫)

ダンジョン飯 三巻

ランド 三巻

ランド(3) (モーニング KC)

ランド(3) (モーニング KC)

建築家が見たマンガの世界

トーマの心臓

トーマの心臓1 萩尾望都Perfect Selection 1 (フラワーコミックススペシャル)

トーマの心臓1 萩尾望都Perfect Selection 1 (フラワーコミックススペシャル)

BONES

BONES ― 動物の骨格と機能美

BONES ― 動物の骨格と機能美

屍者の帝国

沈黙

沈黙 (新潮文庫)

沈黙 (新潮文庫)

やつがしら

やつがしら

やつがしら

旅したら豆腐メンタルなおるかな?

モザイクラセン

今月のベスト本

ペンギン・ハイウェイ」一択です。読後も爽やかだし、成長に伴う痛みもよく描かれているし、何より周りの大人がかっこいい。森見登美彦は今まで読んでなかったけど、これから読んでいこうと思いました。