Posted: Dec 14, 2015 Edited: May 2, 2024 Tags:SystemdConsul Template consul-templateは、consulの様々なイベントをトリガーに指定したテンプレートファイルを元に指定したファイルを更新するためのデーモンです。ユースケースは、HAProxy や Nginx などロードバランサやリバースプロキシのバックエンドを、状態に応じて動的にクラスタ（ロードバランサやリバースプロキシ）へ追加・削除し、可用性や拡張性を高めたい場合などです。今回、同様にnginxとconsul-templateを使って動的リバースプロキシを作ってみましたが、それぞれをsystemdで管理するという点で幾つか学ぶことがありました。私が最初に書いたconsul-templateのconfは以下です。commandによって、nginxのリロードとs
この記事は、HashiCorp Advent Calendar 2015 17日目の記事です。 検証環境の Consul は、 $ consul --version Consul v0.6.0 Consul Protocol: 3 (Understands back to: 1) です。 検証環境は v0.6.0 ですが、v0.6.0 に依存した話しはほとんどないと思います。 筆者は、Consul を Multiple Datacenters(以降、Multi-DC) で運用しております。 Multi-DC で Consul を導入する際に検証した結果を記します。 トピックは以下のとおりです。 WAN DC をまたいで DNS を引く DC をまたいで KV のデータを取得する DC をまたいで KV にデータを入れる Consul Event は複数の DC に一斉に送れない DNS f
この記事は HashiCorp Advent Calendar 2015 - Qiita の２３日目です。（１時間ほど早めに公開したのでブログの日付は２２ですが） 前回の記事 Consul 0.6でユーザのいるshardを探す（Prepared Queryを使う） - kikumotoのメモ帳 の続編です。 id:fujiwara さんの Consul 0.6でユーザのいるshardを探す（Prepared Queryを使う） - kikumotoのメモ帳[consul] 数百万のPQがconsulに登録されても大丈夫なものだろうか2015/12/21 07:25 b.hatena.ne.jp というコメントを受けて、Prepared Queryを１００万件突っ込んでみた結果をまとめます。 結果 先に結果を。 100万件PQを突っ込みましたが、DNSの応答は10件だけ登録のときも、100万
この記事は HashiCorp Advent Calendar 2015 - Qiita の第21日目です。（大人な事情により Hamee Advent Calendar 2015 - Qiita の第20日目でもあります。なので微妙な時間に公開） 概略 ユーザIDをベースにDBを分割（sharding）しているのですが、プログラムからユーザのいるshardを探すのにConsulを使えないかなぁと思って試している話。 Consul0.6のPrepared Queryを使って解決してみました。 目次 背景 前提 方法１（今回採用予定） 方法２ その他の方法 まとめ 背景 ユーザIDをベースにDBを分割（sharding）していると、プログラムからユーザのいるshardを探す必要があります。 これをどこかのメタDBサーバにするってのも良いんだけど、Consul使ってDNSで引っ張ってこれると使
Consul のメジャー・アップデートがありました。Blog 記事があがっていましたので、例によって参考程度にどうぞ。 Consul 0.6 – HashiCorp https://hashicorp.com/blog/consul-0-6.html —-ここから ■ Consul 0.6 私たちは Consul 0.6 のリリースにワクワクしています。今回は多くの新機能や改良が追加されたメジャー・アップデートです。Consul とは最新のデータセンタ・ランタイムです（訳者注：HashiCorpでは、いわゆるネットワーク・システムのことをデータセンタとして表現しています。日本語の物理的なデータセンタとは概念が少し異なります）。Consul は扱いやすい Go 言語のバイナリであり、サービス・ディスカバリ、設定、オーケストレーションの各機能があります。分散と高い可用性、そして、複数のデータセ
Site Reliability Engineering Team（通称SRE）の@cubicdaiyaです。最近チーム名が変わりました。 今回はConsulを利用して複数台のnginxサーバのTLSセッションチケットを自動更新する仕組みについて紹介します。 TLSセッションチケットは簡単に言うとTLSのセッション情報を暗号化してクライアント側に保存することで HTTPS通信時に行われるTLSハンドシェイクの手順を省略してネットワークレイテンシを削減するための仕組みです。(詳細については一番下の参考情報を御覧ください) 似たような仕組みとしてTLSセッションキャッシュがありますが、こちらはセッション情報をサーバ側に保存します。 HTTPS通信ではTCPのハンドシェイクに加えてTLSのハンドシェイクが必要になるのでHTTP通信よりもネットワークのレイテンシが大きくなりますが、 これらの仕組み
ConsulはDNSインターフェースを通してノードとサービスの死活監視の状況を提供することができる e.g. ロードバランスのためラウンドロビンしているノード群を問い合わせ結果として提供するとき、問い合わせ結果からダウンしたノード・サービスを動的に外す DNSをどのようにインターフェースとして利用しているか、を見ていく過程で、DNSについて学ぶことができる www.consul.io localhostでConsulサーバが動いていて、ノードルックアップを行う場合、例えばfoo.node.consulの名前解決を行う際は$ dig @127.0.0.1 -p 8600 foo.node.consul ANYのように行う DNSサフィックスがOSの設定によって自動的に付加されることを防ぐためにFQDNはピリオドで終端するので、DNSサフィックスが不要な場合、digで問い合わせする際にピリオド
環境 Consul Server(0.5.2) x 3 Consul Agent(0.5.2) x 数十台 現象 とある日、プロダクトのConsulクラスタ管理下のサーバがちょいちょいアラート出すので Consulログを確認するとノードが数分間隔で EventMemberFailed と EventMemberJoin を繰り返していた。 特に特定のノード、というわけでもなく、ランダムにノードがFailし、数十秒後にJoinし直す、というログがひっきりなしに出力されていた。 「consul flapping」でぐぐってみると、いくつか同じような現象で悩んでいる事案があるようだった。 原因となったサーバ ほぼ全てのノードがflapping状態だったので原因つかめず途方に暮れていたが、この投稿 で のfromのサーバを見るといいよ、とあったのでgrepしてみるとビンゴ。 そのサーバにログインし
10月 2015 (1) 9月 2015 (1) 12月 2014 (2) 11月 2014 (1) 10月 2014 (1) 9月 2014 (1) 7月 2014 (2) 6月 2014 (2) 5月 2014 (1) 12月 2013 (1) 10月 2013 (1) 7月 2013 (1) 11月 2011 (2) 10月 2011 (1) 5月 2011 (1) 3月 2011 (1) 1月 2011 (1) 12月 2010 (3) 11月 2010 (1) 10月 2010 (1) 9月 2010 (3) 8月 2010 (6) 7月 2010 (1) 5月 2010 (2) 4月 2010 (1)
Consul provides a session mechanism which can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data. They are designed to provide granular locking and are heavily inspired by The Chubby Lock Service for Loosely-Coupled Distributed Systems. Session DesignA session in Consul represents a contract that has very specific semantics. When a
お待ちかね Consul 0.5.0 が出ました -> https://hashicorp.com/blog/consul-0-5.html 今回のリリースでいろんな機能が追加されましたが lock が気になったのでとりあえず動かしてみます。 環境準備 Consulと使いそうなツールを幾つか含んだDockerコンテナで検証してみます。 FROM ubuntu:trusty MAINTAINER foostan ks@fstn.jp RUN apt-get update && apt-get install -y wget curl unzip telnet dnsutils RUN wget http://stedolan.github.io/jq/download/linux64/jq RUN chmod +x jq RUN mv jq /usr/bin ## consul RUN wg
Consul 0.5 がリリースされました。久々のメジャー・アップデートです。新機能や変更点がまとめられた内容が、HashiCorp のブログに投稿されました。例によって、自分の情報整理用の翻訳であり、死蔵しておくのもアレなので、参考程度にどうぞ。 ■ Consul 0.5 私たちは Consul 0.5 のリリースを誇りに思います。Consul とは、現代のデータセンタが必要とする多くの機能、例えば、サービス検出（service discovery）や設定やオーケストレーションなどを行う、データセンタ・ランタイムです。分散や高可用性、千台ものノードにスケールすることの立証や、複数のデータセンタにまたがるサービスを行えるように設計されています。 数か月前に行った Consul のメジャーリリースでは、その驚くべき安定正により、大きな新機能、ユーザ経験の改善、バグ修正に集中することができまし
我々はどのように冗長化を失敗したのか
HashiCorpから、Atlasが正式版 ( General Availability ) になったというブログの投稿がありました。内容把握の参考にと、翻訳しましたので公開します。例によって参考程度にどうぞ。 — ■ Atlas 正式版 (General Availability) 原文：Atlas General Availability – HashiCorp https://www.hashicorp.com/blog/atlas-general-availability.html Atlas 正式版の発表に胸が高まります。Atlas はインフラのバージョン管理システムを作るために、私達の良く知られているオープンソースのツールを積み重げて連携したものです。インフラの変更の自動化・監査・共同作業を、あらゆるインフラ事業者を横断して行います。 2014 年 12 月に Atlas を公
Consul Template これまでの連載の応用として、最後にConsul Templateをご紹介します。SerfやConsulを使えば、複数台のサーバやLinuxコンテナ上で、様々な処理を同時に行うことができます（イベントハンドラ機能）。実行は任意のタイミングで行えるだけでなく、ノードの増減やサービスの増減に応じて自動的に実行できることが特徴です。 自動実行は、増減のタイミングでコマンドを実行するだけでなく、管理用のファイルやロードバランサ等の設定ファイルを書き換えにも利用できます。通常は、設定を書き換えるためのスクリプトやプログラムを準備する必要がありました。 この設定ファイルの自動書き換えに特化したプログラムがConsul Templateです。その名前の通り、Consulクラスタと連携します。あらかじめテンプレート元になるファイルを用意しておくことで、Consul上でのノ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
