絶品ゆどうふのタレ

ふと気づいたことを綴るだけのメモ

Vagrantで `unknown filesystem type 'vboxsf'` のエラーが出た場合

vagrant virtualbox plugin

Vagrantでエラーに当たってちょっと調べ物したので記録しとく。

起きたこと

久しぶりに、Vagrantを使って Ubuntu 15の環境を作ろうとしたところ、 chef_zero provisionerで以下の様なエラーが出た

Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u ubuntu`,gid=`getent group ubuntu | cut -d: -f3` v-csn-cf1999bf2 /tmp/vagrant-chef/890ab396746b083fc8c6a52ec67db241/nodes
mount -t vboxsf -o uid=`id -u ubuntu`,gid=`id -g ubuntu` v-csn-cf1999bf2 /tmp/vagrant-chef/890ab396746b083fc8c6a52ec67db241/nodes

The error output from the last command was:

sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device
mount: unknown filesystem type 'vboxsf'

どうやら、 vboxsfがうまく扱えていなくて、chefが使うnodesなどのディレクトリをGuest側でmountできない。

原因と対策

詳しく調べなかったが、使っていたイメージの Virtualbox GuestAdditions がないか、バージョンが古くてうまく動かない、という状態のようだった。

この問題が発生した場合は最新GuestAdditionsを入れてやればよいが、普通にVirtualBoxの手順でいろいろやろうとすると面倒。

なので vagrnt-vbguest pluginをinstallしておくと、imageの起動時にGuestAdditionをチェックして最新版をインストールしてくれる。

vagrant plugin install vagrant-vbguest`

今回はvagrant chef_zeroでエラーが出てたけど、vagrantで作ったimage全般でできる対策だとは思う。

CarthageでGithubのAPI rate limitに対処する

Carthageって結構ごりごりGithubからcheckoutしてくるので、大勢でやってると

"API rate limit exceeded for xxx.xxx.xxx.xxx. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)"

みたいなことを言われてしまう時があります。

対処法としては Homebrewなどと同様に Github APIのAccess Tokenを使う事になるんですが、Carthageではこのtokenを GITHUB_ACCESS_TOKEN という環境変数に指定することで利用できます。

export GITHUB_ACCESS_TOKEN=xxxxxxxxxxxx
carthage checkout

なお、Githubのtokenは生成時に１度だけしか表示されないので、 .*rcとかの中のコミットしないどこかにこっそり書いておくと良いと思います。

この辺で実装されたようで、利用できるのはcarthage 0.8以上っぽいです。

そんな小ネタ。

iOSシミュレータでの通信状態のテストにNetwork Link Conditionerが便利だった

ios debug network

や、僕が知らなかっただけで世の中では常識の可能性もありますが。めっちゃ便利だった。

ネットワーク悪環境の場合のテスト。。。

iOSのネットワーク環境が悪い場合のテストって前から悩ましいと思ってて、MacのWifiをOffにするとか開発中のアプリを実機に入れて建物の隅っこに行くとか涙ぐましい感じでやってたんですけど。

ちゃんとネットワーク状態を調整してくれるツールあった。

Network Link Conditioner

Apple Developer Center から Hardware IO Tools っていうユーティリティ群をダウンロードすると、その中に入ってる。 他に同梱されてるアプリも便利そうな名前が色々。。。

f:id:Yudoufu:20160528120815p:plain

起動すると、再現したいネットワーク状況が色々選べて、スイッチをONにするとMac上の通信が制限される。

f:id:Yudoufu:20160528120835p:plain

他にも、自分で通信状態を細かく指定したカスタム環境も作成できる。 up/downそれぞれのLoss率と速度などなど。

f:id:Yudoufu:20160528120850p:plain

なお、操作できるのはパケットロスの度合いと通信速度までで、ネットワークON/OFFののテストしたいときは直接MacのwifiをON/OFFしてやることになりそう。

100% Lossとか使うとTimeoutのテストが手軽にできる。 めっちゃ良くて捗りそう。今まで知らなかったのは悔やまれる。

いまさらGAE/Goに入門してみる

最近周囲がGAEづいていて、やったこともなかったので入門してみた。 今の状況的にはやっぱりGoかなと思うので、GAE/Goで。

GCPに登録

まずは登録

https://console.cloud.google.com

初めての人は、60日間有効な$300クレジットがあるのでそれで遊ぶどいいよ (2016/05/21) 登録時にクレカの登録を求められるけど、無料期間が終わっていきなり請求されるわけではないらしい。

プロジェクトを作る

何故か最初からAPI ProjectができていたがApp Engineがほしいので、新しいプロジェクトを作る。特に選択肢なくせずにGAEのプロジェクトができた。 プロジェクト名はご自由に。

AppEngineのページに行くと、言語ごとのチュートリアルも読むことができる。 すごく良く出来てて基本的な使い方を理解できるので、正直やっとくといいよ。

自分はGoのチュートリアルをやった。 チュートリアルを実行すると、リポジトリにサンプルアプリが配置されるので、実行テストにはそれを使いまわすと楽。

App Engine SDK のセットアップ

ちょっと前のドキュメントだとGoogle Platform SDK の gcloudコマンドが統合管理するよ！って感じだったけど、どうやらGAEのSDKはそこからstandaloneになった様子。

https://cloud.google.com/appengine/downloads

ここからpackageを取ってくる。

% curl -O https://storage.googleapis.com/appengine-sdks/featured/go_appengine_sdk_darwin_amd64-1.9.37.zip
% unzip go_appengine_sdk_darwin_amd64-1.9.37.zip

.*shrc 的なものにPATHを通す。

export PATH="/path/to/go_appengine:$PATH"

.*shrcを読みなおしてgoappコマンドにパスが通っている事が確認できればOK。

ローカルでサンプルを動作させてみる

この辺は作りたいものを作ってく感じだけど、とりあえずまずGAEの操作を覚えるのでサンプルのまま。

gae-sample
├── app.yaml
└── hello
    └── hello.go
package hello

import (
    "fmt"
    "net/http"
)

func init() {
    http.HandleFunc("/", handler)
}

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World!")
}
version: 1
runtime: go
api_version: go1

handlers:
- url: /.*
  script: _go_app

上記を作成し、対象ディレクトリをgoapp serve する。

% goapp serve gae-sample
INFO     2016-05-21 04:45:56,681 devappserver2.py:769] Skipping SDK update check.
WARNING  2016-05-21 04:45:56,885 simple_search_stub.py:1146] Could not read search indexes from /var/folders/r8/gnn5k3_j4qq1rjmd3k3x1b4r0000gn/T/appengine.None.yudoufu/search_indexes
INFO     2016-05-21 04:45:56,891 api_server.py:205] Starting API server at: http://localhost:58354
INFO     2016-05-21 04:45:56,897 dispatcher.py:197] Starting module "default" running at: http://localhost:8080
INFO     2016-05-21 04:45:56,901 admin_server.py:116] Starting admin server at: http://localhost:8000

これでローカルにアプリが起動するので、http://localhost:8080/ で動作をチェックできたら完了。 http://localhost:8000/でアプリケーションの状況もチェックできる。

余談だが、最初yamlを書く際にGCP上のサンプルを真似してversion: 1無しで作ったら、GAEにdeployする際に A version or backend parameter is required. と怒られてしまった。 その辺、参考にしたサンプル次第で色々エラーに見舞われると思うのでご注意をば。

GAE上に配置する

今のサンプルをGAE上に配置してみる。

% goapp deploy -application [project id] gae-sample

project idは、作成したGAEプロジェクトのダッシュボード左上あたりに書かれてるので、それを引っ張ってくる。 実行すると、ブラウザ上で認証を求められるので許可すると、デプロイされる。

完了したらhttp://[project id].appspot.comにアクセスすると、動作が確認できる。

これでひとまず、GAEアプリケーションを開発してく準備が整った感じ。

fluent-plugin-elasticsearch(elasticsearch-ruby)で負荷分散してる場合のリトライ設定

fluentd elasticsearch

結論的にはマニュアル以上の情報はないです。個人的メモに近い感じ。

この辺は気軽にテスト/確認しづらいレイヤだと思ってるので、具体的な実装を知らないと怖かったので調べてみました。

背景

  • fluentdからelasticsearchクラスタにログを投入したい
  • サービスから参照されるのでクラスタの一部が死んでもサービスに影響がないようにしたい

世にある記事だと、elasticsearchサーバのローカルにfluentd receiverを置いて、そこからesに投入する形式が多く見られた。

が、それだとreceiverが生きててesプロセスだけが死んだ場合にデータの投入が部分的に止まるよねってことで、送信元のfluentdからesに直接接続して投入することにした。

その場合fluent-plugin-elasticsearchが分散処理を行うので、その部分のfailure/retryの扱いやパラメータを調査した。

ポイント

先に、設定項目とかのまとめだけ。

  • fluent-plugin-elasticsearchは内部的にelasticsearch-ruby(elasticsearch-transport)を利用していて、そこが接続管理をしている。

  • 設定を検討した方がいいelatissearch-rubyの項目は以下

    • reload_connections
      • コネクション先サーバリストの更新可否と、その閾値。trueでdefault 10000リクエスト毎。
      • とりあえずtrueで。クラスタの構成変更の頻度次第で増減させるといいかも。
    • reload_on_failure
      • 接続失敗した場合にサーバリストを更新するか否か。
      • これはtrueにするのが良さそうだが、サービスの監視体制等次第かも。正常にクラスタから外れないまま壊れたサーバが出るとどうなるだろう。。。
      • reload_connectionsの長さとのバランスにもよる。
    • retry_on_failure
      • サーバがunreachableだった場合のretry可否と試行回数。true指定だとdefaultの3が使われる。
      • fluent-plugin-elasticsearchでは5で固定。まぁそんもん感。
    • retry_on_status
      • サーバエラーが返ってきた時にretryするかどうか。
      • クラスタのうちの1台だけが異常になった場合とか想定すると、trueしたい。
        • ...だが、これはfluent-plugin-elasticsearchでは指定できない。

  • 環境次第だがWARNのログも閾値設けて監視の対象とした方が安全そう

    • ここを見ないとLANポート・ケーブル故障とかネットワーク異常系の場合に気づきにくそう

  • reload_connectionsをしていれば無停止でクラスタ構成変更に対応できるが、confの書き換えは忘れず行う必要があるので手順漏れがないよう注意

  • 以下項目は、関連するがdefaultのままでもたぶん支障はない

    • resurrect_after
      • default 60
    • resurrect_timeout
      • fluent-plugin-elasticsearchにはない
    • sniffer_timeout
      • fluent-plugin-elasticsearchにはない

以下詳細

まぁほぼソースコードの解説なので。。。

アクセスエラー処理の流れ

対象となるソースコードはこのあたりにまとまっている。 とくにBase#perform_requestが中心。

  • 指定された選択方式(RRとか)で接続先サーバを決め、リクエストを送る
  • retry対応が走るのは以下のパターンだけで、それ以外は問答無用で死ぬ

unreachableだった場合(Timeout / ConnectionFailed)

  • 対象サーバは死亡判定を受ける
    • reload_on_failureパラメータがあれば、接続不能なサーバにあたった時点で即座にサーバリストのリロードが走る
    • retry_on_failureパラメータが設定されていると、改めてretry
      • max回数を超えるまでは失敗してもWARNしか吐かないので、WARNログをチェックしたほうが良さそう
      • [#{e.class}] Attempt #{tries} connecting to #{connection.host.inspect}

ServerErrorだった場合

  • retry_on_statusパラメータがあるなら、無条件でretry
    • エラーを返したサーバに接続ペナルティはない(dead判定もfailure判定もされない)ので、調子悪いサーバが対象から外れることはない。
    • WARNで出る [#{e.class}] Attempt #{tries} to get response from #{url}のログをちゃんと監視しておくと良いのかもしれない。
    • max失敗するとFatal。default回数は3。retry_on_failureパラメータに数字を渡すと変えられる。
  • パラメータがないならそのまま失敗する！！

なお、fluent-plugin-elasticsearchにはretry_on_statusがないので、この処理は通らない。

死亡判定と復帰判定

サーバの死亡判定はunreachable時、復帰の判定は接続先サーバの選定時に走る。

死亡判定

unreachableになると一旦死亡判定される

  • 死亡判定をされると、メモリ上に死亡フラグと失敗回数インクリメント、死亡時刻が記録される
    • reload_connectionsパラメータがセットされてると、指定リクエスト回数毎にサーバリストのリロードが走る
  • メモリがクリアされると死亡判定は消えちゃうよ
  • 死亡判定されると一旦接続対象から外されて、復帰判定を待つ

復帰判定

unreachableになったサーバにも再度接続のチャンスを与えるために、一定時間経過の後で復帰判定が行われる

  • resurrect_afterパラメータが関与
  • 最後のアクセスからresurrect_after秒後に復活チェック(default: 60sec)
  • 死亡判定を受けたConnectionが、死亡時刻からresurrect_timeout x (2 ** 失敗回数-1) 経っていたら復帰させる

復帰のあと、接続に成功した場合

復帰後にちゃんと接続に成功したら、正常に戻ったと判定されて失敗回数がクリアされる

対象サーバリストのリロード

  • 実際にクラスタにnode情報を取りに行って、対象サーバのリストを更新する
    • その際のtimeoutは別途sniffer_timeoutで決められる(default: 1)
  • この機能を使うことで、設定ファイルのhostsリストを編集・リロードすることなく、クラスタ群の追加削除に対応できる
  • ただし情報はメモリ上にロードされるだけなので、設定ファイルの更新は併せて行う必要がある

だいたいこんな感じ。そんじゃーね。

Kyobashi.swift #1 参加したメモ

http://kyobashi-swift.connpass.com/event/23712/

第1回めだったので、雰囲気も含めてメモメモ

まとめ

  • おにくおいしいです。 リクルートマーケティングパートナーズ さん++
  • 会場が大変にしゃれおつ！
  • drinkup的に、お酒飲みながら。ゆるふわ。
  • みんな軽いLTな感じで、ハードルの上がっている昨今では発表しやすいかも。

以下、聞きながらとったメモ。スライドは上のイベントページを参照のこと

既存プロジェクトにSwiftLintを導入した話

  • Githubが公開してるSwiftのコーディングスタイルガイドに沿っているかチェックしてくれる

  • 導入するのは簡単

  • 今回はチームでいかに導入したかの話

    • チームで合意形成、まずはdisableにしてから徐々に。
    • auto-correctがそこそこやってくれる

ExtraView

  • StoryboardのViewControllerの外側に作れるViewのこと

    • View単体で作れる

  • たとえば: SectionHeader

    • コードで作ったり
    • xibで作ったり
    • やりづらい
  • せっかくならすべての要素を1つのStoryboardで管理したい
    • 整理がついてイメージが作りやすいので、めっちゃ便利

ReSwift

OSSから学ぶSwift実践テクニック

  • Alamofire
    • URLStringConvertible
      • String風に見えるけどじつは違う
      • NSURLでもStringでもなんでも渡せる型
    • extensionをつかってProtocol毎にグルーピングして書くとわかりやすい
    • メソッドチェーンでリクエストを使いやすく
      • 大量のオプションでも見やすく書ける

Nearby Messages API

  • Wifi, BLE, 超音波などで近距離通信できる
  • 100kB以内のデータをやり取りできる
    • (超音波使うのはトークンの交換ぐらいっぽい)

NSError

  • Swift 2.0から導入された新しいエラーハンドリング方式
    • Exceptiionてきなもの

  • Cocoaフレームワーク内のエラーもどんどんこれに置き換わっている

  • NSErrorに存在した詳細なエラー情報がない

  • 定義は空っぽ

  • FriendlyErrorType

  • NSErrorとの共存

DI in Swift

  • DIとは

  • 依存オブジェクトをコンストラクタから差し込む

  • 配線の問題

    • 何かのオブジェクトがほしい時、依存するインスタンスも作らなければいけない

  • Swinject

    • 動的DI
  • Swiftにおける静的なDI
    • Cake Patternっぽいものを使ったDI
    • Protocol Extensionを使ってやってる
    • 読むのはややこしくなる。。。

Swiftは静的言語でも動的言語でもない、という話

swift

swift-evolutionのMLを読んでいたら面白いメールがあったので個人的にメモメモ。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html

Protocol Extensionのmethod dispatchがわかりにくいからdynamicにすべきだ、という提案から徐々に話がそれてSwiftはdynamicかstaticか、いやこうあるべきだどーのこーのと話が揉めてきたところ、Swift作者のChris Lattnerが降臨してSwiftの設計思想についての話を書いていた。

前半は各言語のパラダイムや思想について話していて、その上で後半でSwiftがどういう立ち位置を目指しているのかを説明してる。

スレの流れも含めて要約すると、こんな感じの事言ってるっぽい。

  • Swiftは動作的にはdynamicにもstaticにも属しているわけではなく、予測可能なパフォーマンスとなるモデルにしている。
    • = JIT任せで何でもdynamic、ってのは目指してない。

  • 両者イイトコどりの"opportunitistic" language (日和見的言語)だとしている。

  • 言語的には、基本的にダイナミックだが、それをstatic compilerを使ってJITなしに高いパフォーマンスを実現するように作っている。

    • たとえばnon-publicなクラスをfinalとして解釈することによって、dynamic dispatchのお世話にならずに高速に動作させている
    • memo: Whole Module Optimization とかにも絡む話をしているんだと思わるる

  • 旧来のstaticかdynamicかという話はSwiftでは重要ではなくて、本当に実現したいモデルはProgrammer model

    • Programmer model = メンタルモデルとしてのプログラム言語モデル。プログラマが理解するように動く、というもの。

個人的メモなんで、あんまり正確な書き方になってない。。。（;´▽｀A``英語弱いから誤解してるかもだけど、こんな話みたい。間違ってたら誰か突っ込んでｗ

なお、個人的には元々の提案の方に興味があって見てたんだが、明確な結論は出てないようだった。 話的には、Swift3でそこら辺のdispatchの関係が「もっと理解しやすくなる」のかな。