読者です 読者をやめる 読者になる 読者になる

kikumotoのメモ帳

インフラ・ミドル周りを中心に、興味をもったことを適当な感じで。twitter : @takakiku

builderscon tokyo 2016への感謝

f:id:kikumoto:20161204200949j:plain

YAPC::Asia Tokyoが一区切りを終えた 2015。いろんな枠を超えていたエンジニアのお祭りがなくなるのは、毎年同窓会のような感じでここでしか会っていなかった人たちと会う機会がなくなるのかと思うと、寂しい気持ちでした。 しかし、そのクロージングで @lestrrat さんより builderscon というの発表。 これがどうなるのかなと、すごい期待していました。

そして、2016年になって medium.com というアナウンスが。 この時からなにか自分にできることはないかと思い始めました。

その後、

に参加して、その縁で

とスタッフをさせてもらったりしました。

やはり、builderscon には何か貢献したいという思いは強くなり、またタイミング的に会社的にはエンジニア系イベント(特定範囲に縛られすぎない)のスポンサーを探していたので、一石二鳥(もっとだけど)ということで、会社にふって、まずはスポンサーという形で関わらさせていだきました。

個人的にはもっと関わりたかったので、当日スタッフに応募させていただいて、運良く採用されました。

メインは受付まわりでして、多くの方にスムーズに入場いただけたのはご来場者のご協力あってのものでした。ありがとうございました!

今回はすこしだけセッション担当もさせていただき、また1つスタッフ経験値を得られたかと思います。

当日スタッフごときですが、スタッフするといろいろな経験ができ、いろいろな人と知り合えて、貢献したいといいながらなんだかんだで、自分に戻ってくるものが多いのが素敵です!

とにかく、builderscon 第1回が無事に開催され、いろんな枠を超えてのエンジニアのお祭りとなったのはとても嬉しく、@lestratt さん、そしてコアスタッフのみなさん、当日スタッフのみさなん、もちろん来場者の皆さん、そしてスポンサーの各社様にはとてもとても感謝です!!!

スタッフして思うのは本当に毎回、「感謝!」ということです。

そして、すでに次回の開催に向けて動き始めていますね。

2017.tokyo.builderscon.io

www.slideshare.net

コアスタッフ募集ということなので、それに興味もありつつ、一応会社的なことも踏まえて思案中。でも、最低当日スタッフはまたやりたい!

その前に自分の体力と相談ですね。これだけはもはや気力でカバーできる年齢でもないのがつらいところ。

一来場者としての参加となるかもしれませんが、builderscon 2017 tokyo でみかけたら是非声をかけてください。

もう一度、builderscon に関わったすべての方に感謝!


余談

今回懇親会でのケータリングは、かなり美味しかった。個人的にはこれまでの No.1 だった。

ただし、ビールの No.1 は、iOSDC 2016

この2つが足しあわさって欲しいな。

古いLinux Kernelでfluent-agent-hydraを動かす

fluentd

誰得な記事ですが、晒しておきます。

背景

ワンバイナリで動作するfluent-agent-hydraが適する状況があったので採用することにしました。

が、いざ動作させようとすると、https://github.com/fujiwara/fluent-agent-hydra/blob/master/hydra/in_tail.go#L41 で、fsnotify.Watcher を作成できずに失敗しました。

hydraで使われているfsnotifyはGitHub - fsnotify/fsnotify at v1.4.2で、

とあります。

確かに動作環境は、CentOS/RHEL 5で、カーネルのバージョンが古いです。

こんな環境使うなというご指摘はごもっともですが、そこは闇の世界ということで、これを動かそうとしたのがこの記事です。

対策

inotify自体は Man page of INOTIFY_INIT によると kernel 2.6.13 からあります。で、CentOS/RHEL 5系は 2.6.18 なので inotify はあるはず。

が、 fsnotify は 2.6.27 で追加された inotify_init1() を呼び出しています( https://github.com/fsnotify/fsnotify/blob/v1.4.2/inotify.go#L39 ) 。

一方で、fsnotify の一つ前のバージョン fsnotify.v0 - gopkg.in/fsnotify.v0 では、https://github.com/fsnotify/fsnotify/blob/v0.9.3/fsnotify_linux.go#L111 のように inotify_init() を使っていいます。

ということで、hydra を gopkg.in/fsnotify.v0 を使うように修正してみました。

ビルド方法

ソースは、

github.com

です。

パッケージ名は修正していないので、go get ではインストールできません。また CentOS/RHEL 5 ではSSLの問題ぽくて(詳細未調査)、gopkg.in から clone できないので、別な環境でクロスコンパイルなりをする感じとなります。

以下、手順です。goのインストール、GOPATHの設定は済んでいるものとします。

gox をインストール。

$ go get github.com/mitchellh/gox

ディレクトリを用意して、移動。

$ mkdir -p $GOPATH/src/github.com/fujiwara
$ cd $GOPATH/src/github.com/fujiwara

ソースを取得

$ git clone git@github.com:kikumoto/fluent-agent-hydra.git
$ cd fluent-agent-hydra
$ git checkout el5

ビルド

$ make get-deps
$ make binary

これで、pkg ディレクトリ以下にバイナリができるので、適切なものを実行環境に持っていけば完了です。

とりあえず、これで動作しているぽいです( make test も通りました )。

まとめ

fluent-agent-hydra を CentOS/RHEL 5 といった古いカーネルで動かすようにしました。

GitHub - kikumoto/fluent-agent-hydra: A Fluentd log agent.

これから hydra、とても重宝しそうです。ありがたい。

なお、さすがにこれはPRするようなものではないので、このままにしておくつもりです。

この記事が必要な人が他にいないことを祈ります。

ISUCON6敗退から一週間たってからの振り返り

早いもので、ISUCON6(土曜参戦)から早くも一週間過ぎた。 結果は敗退で、流れは @Leko がまとめてくれているので、基本はそちらをどうぞ。

leko.jp

まぁ今年も悔しい結果に終わったので、その悔しい気持ちのまま書いてもよかったのだけど、少しおついてから来年(?)に向けて振り返りをしてみることにする。

自分の役割は、インフラメインで、あとは全体方針を Leko と考えつつ、ボトルネックがどう変わっていくのか見ていく的な感じでした。

Keep

  • 使われるインフラの事前勉強
  • なんらかのISUCON問題をメンバーと一緒にする。
    • 今回は Pixiv さんの問題 をやった。これと去年の反省を含めて、局所最適化ではなく、大きく変更するための思考回路が多少は身についたと思う。
  • 最低限のタレの準備
    • 必要なツール類(Kataribe とか pt-query-digest とか)やアカウント作成を Ansible ですぐ入れるようにしていた。
    • また、M/W 類は状況に応じてという気がしていたので、基本のインストールスクリプトだけ用意。
  • M/W、OS関連のチューニングはすぐに着手せず、まずは準備が出来次第、自分もコードを読んで作戦面を考える。

Problem

  • Redisをわかってなかった
    • Redis は入れたものの、デフォのまま放置してしまい、アプリ側の挙動を変な状態にしてしまった。これがなければ早いうちに3、4万点台に乗せれていたのでとても悔やまれる。
    • 普段使っていないものは、その場しのぎではダメっていう良い(?)見本です!(申し訳ない)
  • アプリ実装に肩入れしすぎた
    • 今回はベンチがひたすら 0 点が続いて気持ち的な余裕がなくなって、上記 Redis の問題時に自分の本業側の方をきちんと見ずにアプリ実装側を見過ぎていた。
    • 作戦・実装方針以外はまかせて、自分の見るべきところを見るべきであった。

Try

  • ISUCONで使いそうなM/Wは使い込む
    • 普段から使えれば良いが、ISUCONで使いそうなM/Wについては使い込んで、どういう問題が発生するのか特徴を理解しておく。
  • 社内ISUCONの実施
    • いろんな意味で、社内ISUCONをすることでそもそもエンジニアとしての地力をつけたい。
  • 問題の意味することろから攻める
    • 単に重いところをどう軽くするかの方針だけでなく、問題の本質から全体最適化を考えられるようにしたい。

まとめ

今年もよい刺激となり、実力のなさを痛感しました。それでも昨年よりは、点数的にはよくなったと思うので、逆に悔しい気持ちは大きいです。これをバネに日々精進したいです。

ISUCON6の運営のみなさま、今年も楽しい場を設けていただきありがとうございます!

一方で、ISUCON6自体はまだ本線が控えているので、ぜひ諸々頑張ってください!特になにかできるわけではありませんが、応援しています!

iOSDC powered by builderscon に当日スタッフとして参加してきた

builderscon iosdc

iOS Developers Conference Japan 2016 iosdc.jp に当日スタッフとして参加してきました。

(ブログが YAPCスタッフ、JTF登壇と、カンファレンス系ネタが最近多いなと、書きながら感じてるところ)

前夜祭含め、受付をさせてもらってましたので、ほとんどの方とお会いさせていただた感じとなります。 懇親会リストバンドとTシャツを渡しを担当していました。

前夜祭から多くの方にご来場いただいて、カンファレンスとしても大成功といっても良いのではないでしょうか。 受付もご来場者みなさまのおかけで、また他の受付スタッフみなさまのおかけでほぼほぼスムーズにご入場いただけたかなと思います。


ところで、タイトルにも含ませていただきましたが、iOSDC 2016 のページ最下部に

f:id:kikumoto:20160821233214p:plain

とあるのにお気づきでしたでしょうか?

iOSDCは正式に powered by builderscon がついた最初のカンファレンスとなりました(私の認識では)。

そもそも今回当日スタッフをさせていただいたのは builderscon 、およびその流れ(?)で開催された YAPC::Asia Hachioji 2016 mid in Shinagawa でファンになったw @tomzoh さんがiOSDC実行委員長をするからでした。

builderscon そして @tomzoh さんの手助けに微力ながらなれたなら、自分としても大成功だったかなと思っています。

そして builderscon は 12/3 に builderscon.io が開催されます。iOS なみなさまもぜひ参加していただけると良いんじゃないでしょうか。


なにはともあれ、今回スタッフとして参加させていただき、また新しい仲間とめぐりあえて、とても嬉しいです。意外なつながりも発見し、やっぱりスタッフって楽しいなと思いました。 一人一人お礼をいいたいですが、書くのも大変なので、代表して、あらためて実行委員長の @tomzoh さんに感謝したいです。ありがとうございました。

もちろん、スポンサーのみなさま、参加されたみなさま、liveストリーミングで参加されたみなさま、本当にありがとうございました。

この流れだと来年もきっと開催なのかなぁ。その時はまた、なにがしかの形で関われるといいなと思います。

Terraform 0.7でterraform_remote_stateはdeprecated扱い

terraform hashicorp

Terraform 0.7がリリースされましたね。

Terraform 0.7 | HashiCorp

このバージョンからterraform_remote_stateリソースがdeprecated扱いになっています。

今まで

Terraformでの出力を別なTerraformで利用する場合、今まで以下のような感じであったと思います。

出力側
output "repo1_data" {
    value = "Repo1 Data"
}

これをRemote Stateとして、S3に保存するとします。以下のような感じで。

terraform remote config \
    -backend=S3 \
    -backend-config="bucket=bucket-name" \
    -backend-config="key=remote.tfstate" \
    -backend-config="region=ap-northeast-1"
利用側

このRemote Stateを使う側は以下のような感じ。

resource "terraform_remote_state" "repo1" {
    backend = "s3"
    config {
        bucket = "bucket-name"
        key = "remote.tfstate"
        region = "${var.aws_region}"
        profile = "${var.aws_profile}"
    }
}
output "repo1_data" {
    value = "${terraform_remote_state.repo1.output.repo1_data}"
}

これを apply すると以下のように repo1 の出力を取得できます。

$ terraform apply
terraform_remote_state.repo1: Refreshing state... (ID: 2016-08-04 08:26:21.211961588 +0000 UTC)

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

  repo1_data = Repo1 Data

そのままで0.7で実行すると

利用側のコードをそのまま0.7で実行すると

$ terraform apply
There are warnings and/or errors related to your configuration. Please
fix these before continuing.

Warnings:

  * terraform_remote_state.repo1: using terraform_remote_state as a resource is deprecated; consider using the data source instead

No errors found. Continuing with 1 warning(s).

terraform_remote_state.repo1: Refreshing state... (ID: 2016-08-04 08:29:31.623162303 +0000 UTC)

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

と、deprecated と言われ、かつ repo1 の出力を取得できていません。

0.7でとりあえず出力するには

terraform_remote_stateリソースを使いつつ、出力するには以下のように、outputの記述をなくします。

resource "terraform_remote_state" "repo1" {
    backend = "s3"
    config {
        bucket = "bucket-name"
        key = "remote.tfstate"
        region = "${var.aws_region}"
        profile = "${var.aws_profile}"
    }
}
output "repo1_data" {
    value = "${terraform_remote_state.repo1.repo1_data}"
}

この点は、 terraform/CHANGELOG.md at master · hashicorp/terraform · GitHub に記述されているように terraform_remote_stateの出力がトップレベル属性になったからのようです。

とりあえず、0.6 を利用しているひとは、output を削除する必要があります。

これで以下のように warning は出つつ、出力をとれるようになります。

$ terraform apply
There are warnings and/or errors related to your configuration. Please
fix these before continuing.

Warnings:

  * terraform_remote_state.repo1: using terraform_remote_state as a resource is deprecated; consider using the data source instead

No errors found. Continuing with 1 warning(s).

terraform_remote_state.repo1: Refreshing state... (ID: 2016-08-04 08:50:54.409873377 +0000 UTC)

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

repo1_data = Repo1 Data

これから

deprecated の出力はやはり嫌なので、正しい対応としては 0.7 から導入された Data Sources を利用することになります。

Remote Stateに対して 、下記 Data Sources が用意されました。

www.terraform.io

これを利用するには今まで resource と書いていたところを data と書き換えるだけです。出力のoutputを削るのは上記と同じ。

結局以下のような感じ。

data "terraform_remote_state" "repo1" {
    backend = "s3"
    config {
        bucket = "bucket-name"
        key = "remote.tfstate"
        region = "${var.aws_region}"
        profile = "${var.aws_profile}"
    }
}
output "repo1_data" {
    value = "${data.terraform_remote_state.repo1.repo1_data}"
}

実行すると下記のようになります。

$ terraform apply
data.terraform_remote_state.repo1: Refreshing state...

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

repo1_data = Repo1 Data

ということで、これからは Data Sources を利用しましょう、ということですね。

JTF2016で話してきました - HashiCorp Vault + LDAP + MySQL

先日(2017/7/24)に行われた July Tech Festa 2016 でトークが採択されたので話してきました。

タイトル: HashiCorp VaultでMySQLアカウント管理はもう怖くない 2016.techfesta.jp

基本的に前回のエントリ YAPC::Asia Hachioji 2016 mid in Shinagawaで話した、スタッフした! - kikumotoのメモ帳 と同じ内容をしゃべりました。

基本的に話した内容はスライドにある通りです。

一番のポイントは、Vault では認証基盤とアクセス管理対象を、Vault が提供している Auth / Secret Backend の範囲で自由に組みわせられるということです。

GitHub Token を使って、PostgreSQL のアカウント管理なんかもできてしまいます。これを理解していただけると、自分の環境のニーズに合わせて、アカウント管理が安全に柔軟にできるのではと思っています。

あと今回出た質問と回答をまとめておきます。

  • すでにMySQLにアカウントが登録されていた状態だったのか?

    • 私の環境では、そうではなくて管理したいアカウントを新規に作っていくという感じでしたので、既存アカウントの移行という感じではありませんでした。
  • 今回の話し人がアクセスするという話しだったように思えるが、アプリケーションの場合はどうなるのか?

    • Auth Backend に App ID というのがあり、Vault 自体がアプリケーションのにアクセスKeyみたいなのを発行する仕組みがあります。これにより、アプリケーションは必要に応じて都度MySQLのアカウントを生成できて、アプリケーションがconfigに書かれた固定的なMySQLのアカウント・パスワードを使う必要がなくなります。

ということで、7月の2つもトークすることができて満足です。

聞きにきてくださった皆様、本当にありがとうございました。

また、JTFのスタッフの皆様、よいイベントにしていただきありがとうございました。

YAPC::Asia Hachioji 2016 mid in Shinagawaで話した、スタッフした!

vault yapc8oji mysql

YAPC::Asia Hachioji 2016 mid in Shinagawa が、7/2,7/3 で開催されました。 yapcasia8oji-2016mid.hachiojipm.org

トークのお話し

トークが採択されたので、YAPC::Asia Hachioji 2016 mid in Shinagawa の1日目夕方に

github.com

ということで話してきました。

スライドを下記に公開しています。

データのアクセス管理をきちんとしないといけないような環境が前提であったので、ちょっと話しとしてはお堅い内容になってしまったかなとは思います。

それでも必要なところには1つの事例として参考になれば幸いです。

1つ質問をうけて、Consul 側のアクセス管理はどうしているのか、というのをいただきました。

答えとしては、Consul はシステム管理者以外には公開していないので現状はなにもしていないという感じです。

Consul に直接アクセスされてもデータは暗号化されているので情報が取得される心配はないのですが、逆にデータは消そうと思えば消せるので、本質的には良い状態ではないかなと認識しています。ただし、現状ではそのデータを消されても、MySQLの動的アカウントが発行できなくなる程度な使い方しかしていないので、そのうち対策しようかなという感じです。

トークを聞きに来ていただいた皆様ありがとうございました。

スタッフのお話し

また、今回はボランティアスタッフにも参加させてもらいました。担当は受付でしたので、何人かの方は私がチケットをお渡ししていた感じになります。

こういうイベントでのスタッフというのは初体験でしたが、リーダの方々があらかじめ段取りをしておいていただいたおかげで無事に役割をまっとうできたかなと思います。ありがとうございましした。

スタッフやってみて良かったのは、やはり仲間が増えたことでしょうか。第1回ヤパチーのスタッフという共通体験をできた仲間がいるということは今後のいろいろな支えになる気がします。

次回ヤパチーがあれば(あるような流れ)、またスタッフとして参加したいと思える体験でした。

最後に、このYAPC::Asia Hachioji 2016 mid in Shinagawaを開催してくれた @uzulla , @makamaka さんに感謝です。