smallpalace's blog

鯖缶主婦の日々の記録です

#consulcasual 1に行ってみた

勉強会・セミナー 自動化

こんにちは。smallpalaceです。

Consulは使ったことないけど名前解決まわりを自動化したい人用のHashiCorp製品くらいの緩い認識でバリバリ使っている人の話を聞きに行こうかなと思って行ってみました。参加前時点だと、HashiCorp製品は手動オペレーション完全排除可能な環境のみに適している印象。

嬢ちゃん(4)はおばあさま(神)にお願いしておきました。超ありがたや。

ハッシュタグなどは以下になります。

#consulcasual hashtag on Twitter

Consul Casual Talks #1 - connpass

-----------------------

 ぜんぶつさん、概要を話してくださると。

Consul by HashiCorp ～サービス・ディスカバリ入門～ - Qiita

Consulはデータセンタに革命をもたらしたい製品群のうちの一つ、インフラ上のサービス設定とサービスディスカバリーのためのもの。

役割とipやポート単位で管理できるっぽいので名前だけでもないっぽいようだ。

エージェントが必要な模様。ヘルスチェックを自分でやってサーバに通知する。

通知の仕組みはいろいろあるっぽい

あー、監視システムなのね。zabbixとかのかわりか。

集めたデータをどこにおくか、階層的なkeyvaluestoreらしい。3台構成で動かさなければならないと。冗長のしくみありでリーダーを自動選出。Gossipプロトコルつかってるので大規模もいけるらしい。

Consulは運用管理が楽ちんらしい。開発元の思想が”いかに楽に多くを管理するか”ということらしいので。

いれかたはバイナリを解凍しておいとけばおっけー

シンプルなconfをおいてhandlerで状態変化を検知後にスクリプトを実行するなども可能。

Consul Templateという楽ちんなやつがある。設定ファイルを自動生成してプログラムを再起動とかできるらしい。hostsかきかえるとかも。バイナリ配布されているっぽい。

ドライラン機能があるので実行前後のチェックはそれでできるとのこと。

DNS機能は数千台とかのレベルだとトラフィックがバカにならないのでは、ということでした。

---------------------------

@studio3104 Prometheus meets Consul

・Consul ACL System

まだためしてる段階。未来につかうことを考えた場合に、予期しないトラブルを制限したいと。consul execで要るファイルけしちゃう事故のこわい例が。

acl関連の項目がいろいろ。とくに重要な３つ

acl_datacenter　所属する場所を宣言

acl_default_policy　明示しなければホワイトリストに。

acl_master_token　

マルチデータセンタで使うときの話

トークンを明示しないとAnonimous権限になり何も実行できなくなる

ドキュメントにはReadがあればいいと書いてあるが実際はwriteがないと動かない模様。

 

・Whats prometheus？

モニタリングシステムの一つらしい

プルタイプアーキテクチャ

各サーバにhttpいれといてプロメテウスサーバがポーリングしにいく

プロメテウスにはカタログAPIと連携する機能をサポートしている

 

複数のサービスで統合監視ツールとして使っているのでNGINXの再起動したいけど全部でやってしまわないようにACLが必要になったそうです。

-------------------------------

 GMOのひとのプロダクションでやってるはなし。rubyこみったのかた。

Consul in Production // Speaker Deck

ハンドメイド作品売買のminneの裏側。

DCの機能はつかってないOpenStack9割。consul+dnsmasqでやってる

strecherをつかったデプロイ（省略

おまけ、systemdでデーモン化してつかってるそうです

NewRelicのホスト選定をConsulつかってやってる、一台たかいけど交渉したら下がった。便利だけどたかい

roleのなかから1台だけ有効にしたかった。ディプロマットというライブラリをつかってアクセスしてる。

sidekiq-schedulerとか、cronは1vmがSPOFになりがちなのでやめたい。クラスタの中の1台だけジョブの定期実行を有効化するのにconsulつかってる。ホストが死んだらクラスタのなかでワーカーをプロモートする仕組みを作り中。

ロードバランサのDNS更新にもつかってる。AWSからOpenStackに引っ越すときにつかった。collectorというみどるぇあをつかっている。route53を更新するもの。consul watchでcollectorを監視してイベントをフックしてcheckhttpみたいなんでそれぞれのLBの自分がしんでたらconsulのイベント通知がでるのでそこを切り離すというのをやってる。

nginxのupstream自動更新とか

systemdとconsul templateの組み合わせの地雷があるそう。

ルーティング間違えたnodeをconsulのなかにいれるとクラスタ全体が不安定になりnginxが1分間に3,4回reloadするみたいなことに。nginx_mrubyでメモリリークバグがありreloadで落ちるということになったそうです。

vmを束ねて一つのシステムとして扱うことが可能になる

consul maintを活用できてないのでいいかんじにvmを退避するとかしたい

全自動なめらかサーバリソース制御くん、全自動なめらかジョブスケジューラを今作ってるらしい

Reloadすくなくするとかは？

→こちらは一回だけしたいのにイベント発火の関係上３かいくらいになったりする。BGデプロイしたときにreloadしすぎてこまっている

構成管理ツールとのすみわけ？

→完全に分離している。それだけは独立して一切さわらない。

　別名や別のディレクトリで運用するなど

nginxmrubyで独自に管理もできるがcosulでやってる理由は？

→nginxmrubyの機能は同僚がテスト開発中

信頼できるホスト情報をどこでかんりするか？もう一方のあらかじめホスト情報とうろくするものとそのほかと？

→consulとかほかのAPIのホスト情報の祖語の扱いは2つを合うか確認して信頼性を担保している。なやみどころ、

------------------------------------

平和なConsulCluster

ふじわらさん＠カヤック

平和なConsul Cluster運用 / consul-casual-1 // Speaker Deck

3台以上のところでConsulつかっている

活用事例、

１．InternalDNS

ノード名などなどに。

まともにやると負荷になるが、dnsmasqというローカルホスト全台でうごかして、.consulドメインのなまえ解決はconsul agentへ。ttlのあいだはローカルをみにいく。

 

２．maintでメンテナンス

AMIつくるときにつかう、

デーモンツールで起動したくないときにつかうなど

 

３．Stretcherによるデプロイ、chef実行

デプロイツール、S3にtarをおいといてとってきて展開してくれるやつ。

Chef-serverをすててStretcher＋Chef-soloにしたと。どこもおなじようなことしてるんだな。

ConsulでroleにタグをつけとくとカタログAPIで解決できると。jsonかえってくる。

Daemontools管理プロセスを再起動したいとかホストの一覧かえってきたやつを正規表現にまっちしたやつだけ再起動さすみたいな。

WebSocketでうごくbotを排他制御するのをConsul lockでロックを取得できたやつだけがうごくやつをうんようしてる。Readerチェンジがおきるとロックが解放されちゃうので注意。

平和に運用するためのポイント

raftアルゴリズムをよくみてつかう

リーダー選出に過半数の合意がひつよう（だから半分おちると合意がとれない、奇数台でうごかすのがいいと。

t2.mediamとかでもうごくがkvうごかすとメモリは食う。tmpfsつかってDiskIOの影響を回避している。

Rollingupgradeが可能と。

オペミスしすぎるとクラスタが回復不能になる。

Reader入れ替えは２～4秒で可能らしい。

怖い話、catしたあとにgrepとかの結果をkvsにいれるとか肥大化してしまう

ちゃんと起動してないのに過半数以上おとしてしまった→崩壊

 

崩壊したらどうすれば

１．落ち着く

２．サーバを全部とめる

３．データを全部消す

４．serverを-bootstrap-exect Nで起動

５．必要ならKVをバックアップから戻す

 

開発、本番用にクラスタ管理側もわけてる、execとかこわいので。

サービスのDNSに依存さすのは崩壊こわいならやめたほうがいいらしい。

---------------------------------

Consulでロードバランサを管理するはなし

cubicdaiya@mercari

 

nginxとoepnestyつかってる

・Service discovery

内部リクエストのエンドポイントとしてDNS－RRとかAPIなど

いろんなサブシステムがあって管理ツール、バッチ、ウェブアプリ、、http経由でロードバランサを経由してコールするときの内部DNSとして

サービスをリストする。ロードバランサのノードをあつめてくるときにもつかってる

デプロイぼっとが時間になるとデプロイしますかときいてくる、yesとこたえるとデプロイがはじまる

メルカリにおける継続的なapplication改善を支える技術、というのに詳細が書いてある

メルカリではConsulイベントとストレッチャーをいまのところつかっている

consulのeventは100バイト以下におさえて配布したほうがいいらしい。Triggerとかつかうと解決できるらしい

 

Sessionチケットで48バイトになってないかのチェック

→最初の時点でチェックいれただけ

--------------------------------

終了。ありがとうございました！

レベルが高くて脳みそ疲れました。

 けっこうコツがいるっぽいですね。

 

では、見ていただいてありがとうございました(・ω・)ノ