YAPC参加メモ 8/20 前夜祭
YAPC参加メモ 8/20 前夜祭
言語開発の現場 ペパボ柴田さん
- ruby開発の現場の裏側紹介
- MatzはDirector 数年はrubyコードは書いていない
- 担当領域はあったりなかったり。
- サポートしてくれる人が居ればサポートOSになる
- Windowsの方がOX Xよりサポート早いかも?
- rubyは日本人コミッタが多く日本内で決められているように海外から見られているので
対面で英語でやるDeveloper Meetingを毎月開催してる
- 松本さんも毎月出る機会
- 大変なこと:リリース この前も2時間のつもりが4時間かかった
言語開発ってruby以外はほぼ海外なので、身近に日本語でこういった内容をシェアしてもらえるのは貴重。
ruby committersがC programmerというのは言われてみればそうだけど面白い。
はてなブックマークのトピックページの裏側 skozawaさん
大盛況で立ち見状態で床に座って声だけ聴いてた。なので雰囲気だけ。
- 本文の生成?が30分かかる 6ノード
- ニュースタイトルからの生成が主なのでおかしなトピックが生成されてることはあまりない
- 判定は今のところはまだ主観
- 時系列を含めれるようにしたい。
Elasticsearchの知見はお面白そうなので後で見てみたい。 社内で誰か見てそう。
我々にできるOSSとそのコミュニティの育てかた tagomorisさん
既に酔っ払ってメモなし!
作れないけど貢献はしたいので参考になる。
プルリク一応英語で書くようにしてるけど、相手がどう思っているかは・・・
質とコミュニティ発展の関係性に関する和田さんの質問が深すぎてヤバイ。
あっ、perlの話聴いてないぞ・・・
Ansible Dark Side
Ansibleは非常にシンプルかつ強力なツールですが、 様々な設定方法・書き方が許容されるがゆえにやり過ぎると収集がつかなくなります。 そんな若干やりすぎかもしれない設定の一部を晒してみます。 タイトルは若干大げさですが、お勧めするような設定ではないという自虐的な意味を込めてます。
production/staging environment variables
Ansibleである程度の規模のプロビジョニングをするようになると 公式DocumentにもあるBest Practices に倣うと思いますが、 この時課題の1つとなるのがproductionとstagingで異なる環境変数をどう管理するかです。
検索してみると何種類かのやり方がHitするのですが、うちでやっている方法も書いてみます。 このやり方はAnsible始めた頃に同僚から教えてもらった方法です。
inventory/ production/ group_vars/ all group1 group2 hosts staging/ group_vars/ all group1 group2 hosts roles/ site.yml
group_vars + hostsファイルという構成を
productionとstagingのそれぞれのディレクトリに作ります。
こうするとall
はproduction全体・staging全体を表すことになるので、
それぞれに適用したい変数を設定できますし、
group1、group2も環境毎の値を設定できます。
実行する際は、
ansible-playbook site.yml -i inventory/production/
デメリットはproduction/staging共通の設定であっても2箇所に書く必要があることです。 そのためパスは少し深くなりますがinventoryというディレクトリの中に両方を入れて、 ネストしてみせることで両方設定する必要がある、 というのを意識しやすくしています。 (並び順がバラけるのを防ぐ意味もある) 自分は更にlocalというディレクトリも作って 手元のvagrant上でレシピをテストする時に使ってます。 (.gitignoreで登録対象からは外す)
大外に共通用のgroup_vars作ればいいかもしれませんがgroup_varsが複数個所にあると 管理が更に煩雑になる気もするのでこのくらいが自分には限界の気がします。
large repository management
サービスがある程度の規模になってきてチームで運用が分かれたり、 小規模でも複数のサービスを同時に運用するようになると、 レシピの管理単位を分割したくなります。 一方で、共有したいRoleも当然あります。 以下を参考にしてディレクトリ構造を組みました。
参考にしつつ試行錯誤して自分なりの設定を加えています。
common-roles/ vars/ filter_plugins/ roles/ jdk/ nginx/ mackerel_agent/ team1/ inventory/ roles/ app1/ ansible.cfg site.yml team2/ inventory/ roles/ app2/ ansible.cfg site.yml
$ cat team1/site.yml - hosts: app sudo: yes vars_files: - ../common-roles/vars/xxx_vars.yml roles: - jdk - nginx - app1 - mackerel_agent
参考サイトと異なるのはcommon-rolesのRoleもteam1のRoleも同じように指定できるところ。 これを実現するためにansible.cfgを各実行ディレクトリに置いています。
$ cat team1/ansible.cfg [defaults] roles_path = ../common-roles/roles/ filter_plugins = ../common-roles/filter_plugins
関係ある設定はこんな感じでcommon-rolesのパスを設定すると、 設定したパスのRoleと実行ディレクトリ配下のRoleの両方読んでくれます。 filter_pluginsも同様に出来ました。 同様には出来なかったのがlibraryのパス設定で、 これは要するにmoduleを読むパスなんですが、 設定するとそのパスのみが有効になってしまい、 Ansible組み込みのmodule群が使えなくなってしまったので、 libraryに関しては実行ディレクトリ配下か、Role内にのみ置いて使っています。 それから共通で使うvars_fileみたいなのはそんなに数多くないし 相対パスで指定してます。
Ansibleは本来はもっとシンプルに運用可能なツールで、 library, group_vars, roles, xxx_plugins みたいな決まった名前のディレクトリを 実行ディレクトリ配下に置いていると勝手に読んでくれるので、 可能ならansible.cfgとか使わずに済んだ方がスッキリできるとは思います。 (接続性の設定とかは別)
Include various settings
mackerelとかtd-agentとか横断的に利用し、 かつ複数の設定をもつようなRoleがあります。 パターンの種類が少ないうちは種類ごとに分けたファイルをinclude + whenで 処理していました。
roles/ mackerel_agent/ tasks/ configure_a.yml configure_b.yml main.yml $ cat main.yml - include: configure_a.yml when: mackerel_agent_type == 'aaa' - include: configure_b.yml when: mackerel_agent_type == 'bbb'
この手法は分岐条件が少ないうちはまぁなんとかなりますが、 パターンが増えてくると徐々に扱いづらくなってきます。 ソースも見づらくなってきますし、実行時のログがwhenの場合は実行されない条件でも skippedとしてログに出てしまうので実行結果が読みにくいです。
解決策としては2種類考えました。
1つはinclude
するファイル名を変数化することです。
- include: configure_{{ mackerel_agent_type }}.yml
しかし課題もあり、group_varsでこの変数を指定しようとすると失敗します。 理由は、変数を読む順番のためだと思っています。
参考: Ansible の変数の優先順
group_varsよりplaybook role parameterの優先順の方が早いので、 playbook role parameterを読み取るためにincludeしようとして そんなファイルは無い、となります。 playbook vars (site.ymlの先頭にvars:で書く)で指定するとうまくいきます。 playbook毎に適用種類は決まる気がするので 今は一旦この方法でやろうと考えていています。
記事を書いているうちにもう1つの案が実はよりよく感じてきました。 もう1つの案とはRoleを分けることです。 Ansibleを運用する場合、多くの場合でRoleを適宜分割することは良い案です。 特にサービスに依存するような設定を行う場合、 ミドルウェアのインストールのような汎用的な部分と、 ミドルウェアの設定をサービスに合わせて行う部分は分けた方が良いです。 更に後者から前者にDependencyを設定しておけば後者のみ指定でよくなります。
roles/ mackerel_agent/ mackerel_agent_serviceA/ mackerel_agent_serviceB/ $ cat site.yml roles: - mackerel_agent_serviceA
デメリットはRoleが複数増えてしまうことと、共通の変数を設定しているような場合に 設定箇所が散らばってしまうことでしょうか。 共通のRoleがやたら増えるのも困るので今は1つ目の案で考えています。 (refactoring now...)
以上、3つほど運用パターンを晒してみました。 これらは決して勧めているわけではなく、 多分、ここまでやる前に構成や運用を見直した方が良い気がするのですが、 こういった事も出来るよ(やっちゃってるよ)という記事でした。
ちなみにちょっと気になって、 初心者Chefアンチパターン を久々に見返したらほぼ当てはまっていて今回の内容もだいぶやばいかも。。
Ansible入門を開催した話
だいぶ時間がたってしまいましたが、
7月1日にAnsible入門をハンズオン形式で
開催しました。
弊社ではエンジニア・デザイナー・ライター陣の取り組みとして
毎日何かしらの勉強会を開催
していてその一環ですが、
折角なので何かテーマを持って実施したいと思って、
『開発環境をAnsibleで作る』を目標として入れてみました。
インフラエンジニアがProvisioningとして使うだけでなく、
アプリケーションエンジニアも開発を補助する環境を
Vagrant+Ansibleで作れるようになろう、という意味です。
実際にハンズオンに使った資料は以下にあります。
https://github.com/ki38sato/ansible-hands-on
ハンズオンと言っても大量の細かい設定をもつplaybookを その場で1から書くのは難しいので、 サンプルレシピを用意してその内容を説明しつつ手元のVagrantで実行してもらって 動作を体験してもらうという形にしました。 目標を達成できたかは微妙なのですが、Ansibleをある程度動かせる知識を 垣間見てもらうことは出来たのではないでしょうか。
当日は何故かその日に限ってVagrantfileに問題が起きていて、 ansibleをインストールするためのyum repoが読み取れない状態になって 講師の自分が環境を構築できず、バタバタしてしまいました。 最終的に@key_ambさんに助けていただきました。さすがすぎる。ありがとうございました。 1年くらいほぼ同じの使ってるのに初めて問題がこのタイミングで起きるのは 日ごろの行いのせいでしょうか。
当日喋るつもりだった内容の1/3も話せなかった気がしますが、 折角資料作ったのでブラッシュアップしつつまた開催したり、 あるいは次のステップ(more..と書いているがやってない部分の説明とか)も 計画できたらいいなぁと思っていますが、 根性がないタイプなのでどうなるかわかりません。
Mackerel Meetup #4 Tokyo で発表してきた話
5/26 (Tue.)にMackerel Meetup #4 Tokyo にて、自社サービスでMackerel導入して使っている話をしてきました。
www.slideshare.net
発表にいたるには色々と乗り越えなきゃならない壁があって、 自分なんかでいいのかとか、全然技術的な話がないとか、 台風とか、更には開発してるサービスが正式リリースの当日 みたいなのがあって追い込まれすぎた結果一周して開き直れました。
ただやっぱり不慣れな面は出るもので、画面解像度合わずに端切れてたり、 話すつもりの内容が飛んで発表時間が短くなったりご迷惑をおかけしました。 説明の少ない資料で当日うまく話せなかった部分もあるので少しだけ補足しておこうと思います。
Host metric: 60+ Role, 100+(host)相当
productionと検証、開発リソース全てを含んでいます。
インフラリソース(JenkinsとかKibanaとか)も含んでいます。
リリース日前後ということでサーバによっては統廃合ある関係で平常時よりも多かったりもします。
マイクロサービスアーキテクチャということで、台数のわりに種類が多いです。
そんな状況ですがMackerelのService
&Role
機能がフィットして運用上の負担を感じていません。
%で横断的に設定できるのでスケールしやすいです。
Service metric: 50+ Services
マルチサービスアーキテクチャで機能毎に分割してるので、
例えば、メインAPIにサブ機能が2つあったら、APIサーバが3つになります。
当然それぞれELBとRDSがつく構成である場合が多いです。
これだけなら、Service
を3つ作ってやればService
は増えちゃうけど一応回る。
しかし、
とかで、溢れたELBやRDSを単独で収容するService
が出来たりします。
それにそもそも3つのAPIが同じような機能グループだったら1つのService
にRole
として同居したい、という風に思ったりもします。(好みはあると思いますが)
またService metricはHost metricと違って1項目毎に監視が独立してるので、 RDSx3台x3項目+ELBx3台x1項目を設定しなければなりませんし、 こちらは%設定じゃないのでそれぞれの閾値を値で設定する必要があります。 監視登録APIが出来ればあるいは解決する話かもしれませんが、例えば
- 共通ルールを作って割り当てれる
- MaxとCurrentを指定して%チェックルール作れたり
とか、妄想してます。(これは伝え忘れた、、、)
やはりhost metricと同種の便利さをService metricにも期待したい。
複数のELBやRDSを1つのService
にRole
っぽく紐付けて、、、
と、色々尽きないので大変だとは思いますが素敵なソリューションを期待します。
mkr + cron
発表では触れ忘れましたがmkr + cronは少しだけ課題があって、 mackerel-agent同様に1分間隔でmetric送信を実施していて、 ELB/RDSが増えるにしたがってTIME_WAITが溜まるようになったので注意が必要です。 cronでこの量を毎分起動するのはイマイチだなぁとも思っているので、 何かスケジューラーを入れるか、あるいはmackerel-agentがservice metricも キックできてその辺の問題も勝手にクリアされればと思っていたりします。
Notification
通知を課題にあげようとしたら発表されてた。改良早い。Mackerelサイコー
運用コスト
自分が最初に楽をしたいと思ったのは監視サーバ自体の運用の部分で、 プラスでSlack連携やスマホ対応がついてきて総合的にも便利という話。
mackerelの導入についての関心
コミュ障ながらも懇親会で何人かの方とお話させてもらった話題の中に、 Saasなだけに導入の説得をどうするか、という関心はけっこうあったみたいです。 自分としても「ゆるふわ運用でも楽で便利」みたいな線は狙ってはいたのですが、 試した後で導入に漕ぎ付ける部分では期待には応えれてない。 それでも今後も便利さは加速すると思うので機会があれば是非。
まとめ
発表者特典で色んな人に声かけてもらえましたが話せなかった人も多くて、 後で名刺交換のつもりが時間切れになってしまっていたりとか。 songmuさん、腰低すぎ。鯖T、リクエストすれば良かった。言いたいことがまとまらないのでこの辺りで。 めったにない機会だったので色々思い残すこともあったのですが、無事済んで良かったという思いで一杯です。 (WBS放映は普段よりアクセス来ましたが想定内で事なきを得ました。)
はてなさん、フリークアウトさん、参加者の皆さん、ありがとうございました。お疲れ様でした。
rootでjstatできなかった話(Jdk8u40)
※この話は時限的なものなので注意が必要です。
sudo jstat が実行できずにハマりました。
sudo jpsを実施するとprocess information unavailableと表示されます。
最初はjdk 8u40
で遭遇したのですが、jdk 8u31
以降のようです。
java実行ユーザでは実行できます。
実行ユーザ以外はrootでも実行できなくする仕様変更か?とか疑いましたが、調べた所、Issueっぽいのを見つけました。
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1417962
https://bugs.openjdk.java.net/browse/JDK-8073858?page=com.atlassian.streams.streams-jira-plugin:activity-stream-issue-tab
jdk 8u60
でも直ってない?
Java8に上げたらmackerel-plugin-jvmの結果がとれてなさそうだったので調べた所、mackerel-plugin-jvmの内部で使用しているjps, jstatに問題を発見したという流れです。
現在はmackerelのconfigで
[plugin.metrics.jvm] command = "sudo -u 実行ユーザ /path/to/mackerel-plugin-jvm ..."
みたいにして回避しています。
(5/2追記) プログラムでsudoするにはttyの設定も必要です。
Ansible1.9+centos6.5でAlternativesが動かなくてハマッた話
※この話は時限的なものなので注意が必要です。
※自分が把握してるのはcentos 6.5 + ansible 1.9.0.1-2.el6
の話です。
※(4/30追記)Ansible1.9.1が4/28にリリースされcentos6.5でもAlternativesモジュールが動作しました。
2015/03/25にAnsible 1.9 がリリースされて結構なアップデートが入り、
AWS関係で利用したいものが結構あったので手元で試してみました。
その結果、たまたまJDKを入れる際に使っているAlternativesモジュールが動かない問題にあたりました。
原因は、今まで対応されてなかったcentos(RHEL)の処理がcentos7相当のupdate-alternativesのoptionを用いて実装された結果、該当optionの存在しないcentos6以前で失敗するようになった、らしいです。
それ以前はcentos対応無かったけどelseでうまいこと動いていたというものらしい。
(参考: Ansible Extraとalternativesモジュールの話 | Ansible Advent Calendar2014 <= 後半部)
(参考: Fix multiple issues with alternatives module #313)
既にこの件についてはパッチが出ているので、取り込まれるまで静観しよう、
と3月の時点でなって一旦忘れておりました。
ところがつい先週、同僚氏から
「なんかアプリのvagrantが失敗するようになってしまいました。」
と言われてこの問題が再燃するわけです。
アプリのvagrantは、とあるプロジェクト専用のローカル開発環境用に用意したVagrantfileのことで、
vagrant up時にansibleをguest box内にインストールしレシピを流して環境を作っています。
こうすることで各人の環境依存が減ったり、個人のインストール作業の手間が減りますし、
Vagrantfileはプロジェクトのレポジトリに入れてあるので、
アプリ依存の変更内容も、該当プルリクを教えてもらうことで、
setup用のレシピにフィードバックできたりもしています。
という代物だったのですが、ansibleはprovision時にyum*1*2で入れていたので
そのタイミングで上記の問題が急に発生するようになったのでした。
setup用に使用している1.8.4では発生してなかったので1.8.4のrpmを探したのですが見つからなかったので、
Ansibleインストール後に上記のGithubのファイルを上書きする強硬手段で解決しました。
setup用のAnsibleもこの方法でバージョン上げてしまうか悩んでいるのですが、
入れてもすぐにアップデート分を採用するレシピを書く余裕がないので素直に待ちでしょうか・・・
2014年振り返り
2014年振り返り
今年は色々とタフな1年でした。
7月にSIerからIT事業会社に転職しました。
元々はJava屋でしたが、今はインフラ担当的なところをやってます。
DevOpsっぽい立ち居地でいければいいかなと。
新鮮な気持ちで色々挑戦してます。
あとは転職後すぐに母が亡くなって親孝行もしきれないままという想いが強いですが、
今の会社で頑張ることで恩返ししたい気持ち。
今年初挑戦したこと
- Scala/play
- AWS operation
- Ansible
- sensu/graphite/influxdb/grafana
- mackerel/newrelic
- kibana4
今年買った本
- ハイパフォーマンスブラウザネットワーキング
- 検索エンジン自作入門
- Chef実践入門
- Chef活用ガイド
- Team Geak
- インフラデザインパターン
- マスタリングTCP/IP入門編
- 実践Vagrant
- すごいErlang ゆかいに学ぼう!
- エンジニアのためのデータ可視化実践入門
- Rubyによるクローラー開発技法
- ElasticSearch Server
- GitHub実践入門
- Java逆引きレシピ
- Scala逆引きレシピ
- 入門Ansible
- WEB+DB PRESSや養成読本等
全然読めてなry
転職後ChefからAnsibleに環境が変わったのでChef本2冊がだいぶ浮いてる。
Scalaの環境になったので逆引きレシピ様様でしたがコップ本にいく前にインフラ担当に、、、
今年参加した勉強会
- 1/29 asakusa framework勉強会
- 2/7 elasticsearch勉強会
- 3/5 自作サーバ同窓会
- 3/7 歌舞伎座tech #3 Erlang/OTP
- 3/17 sonic garden study RubyMine
- 4/7 JVM Operation Casual Talks
- 4/21 elasticsearch勉強会 #4
- 5/14 gree tech talk #05 平行/並列プログラミング
- 6/3 WebRTC Meetup Tokyo #2
- 6/24 sonic garden study
- 7/14 elasticsearch勉強会 #5
- 7/20 hbstudy #60 Serf Consul
- 8/29 MQTT Meetup Tokyo
- 9/16 elasticsearch勉強会 #6
- 9/22 Ansible meetup
- 9/24 gree tech talk #06 Go
- 10/31 AWS casual talk #03
- 11/18 elasticsearch勉強会 #7
- 12/10 ISUCON Maker Casual Talks
毎月何かしら参加。
社内勉強会もあるので今後は頻度減るかもしれませんが、継続していきたいと思います。
しかし人見知りなので特に社外に知り合いも増えてないのが残念なところ。
新環境になって色々やってるものの全然アウトプットできてないのも残念。
2015年はもっとアウトプットできるようにと思ってます。
振り返りってよりメモっぽいけど細かいこと考え出すとキリ無いのでこの辺で終了。