YAPC::Asia 2015 http://yapcasia.org/2015/talk/edit/b335dee0-09ad-11e5-8d7a-67dc7d574c3a
There are two sides to monitoring – exposing problems with alerts and acting upon those alerts to find solutions to the exposed problem. For exposing problems, users can define any script for Consul to intelligently check and report the health status of all nodes in a cluster. These scripts could be as simple as returning a 200, or as complex as querying the load and query response time on a datab
Overview dockerをそれなりに扱おうと思うと直面するのがマルチホスト環境でのdockerの構成。 大抵シングルホストのプリミティブな環境では問題無かったL3/L4の扱い、IPアドレス、ポート等のメタデータのリソース管理が問題になってくる。 前者に関しては、ルーティングコンテナ経由でのパケット交換、cgroup/namespaced、Open vSwtichなどでSDNを実装、 L3/L4を抽象化し仮想的に1つのネットワークとして扱えるようにすることで解決をしようという動きがある。 代表的なソリューションとしてはsocketplane, weave, pipework, flannel, Open vSwitch等のソリューションがある。 後者に関して分散Key Valueストアにコンテナのメタデータを登録し必要に応じてクラスタの構成情報を読み出す ことで解決しようとする動きがあ
etcd/consulに認証情報を安全に保存する 分散Key-Valueストアとしてetcdやconsulの利用が増えている.ここにアプリケーションの設定値などを保存し,各ホストからそれらを購読して利用する. また,X-as-a-Serviceといった外部サービスの利用も多くなってきた.その場合API Tokenやパスワードといった認証情報が必要になる.PaaSやTwelve-factor的なアーキテクチャを採用する場合は,それらの値を環境変数に保存して利用することが多い(危険であるという意見はある.cf. http://techlife.cookpad.com/entry/envchain).etcdやconsulといった分散Key-Valueストアの利用を前提としたアーキテクチャでは,そこに外部に漏らしたくない設定値も一緒に保存してしまうのがシンプルになる. しかし,そういった設定値を
はじめに Dockerを利用するとコンテナをぽこぽこ沢山立てることが多いと思います。 コンテナが沢山できるので、それらに対していかに効率よくアクセス出来るかが肝になります。 またコンテナで提供するサービスのポートをホストに割り当てて利用する場合(-pオプションを利用する場合)、 ポコポコ出来るコンテナのポートを静的に(-p 80:8080みたいに)割り当てるのは面倒です。 なので動的に(-p 80みたいにしてホストの適当なポートに)割り当てたいところです。 ただし、動的に割り当てるとどのコンテナがどのポートでサービスを提供しているか把握するのが難しくなり、さらにマルチホストになるとどのホストで動いているかどうかを把握する必要もあり、これも難しいです。 この辺うまいこと出来ないかな、ということでServiceDiscoveryといったらConsulですよねってことで組み合わせて使ってみます。
Orchestrating Docker with Terraform and Consul by Mitchell Hashimoto Terraform is a tool for building and safely iterating on infrastructure, while Consul provides service discovery, monitoring and orchestration. In this talk we discuss using Terraform and Consul together to build a Docker-based Service Oriented Architecture at scale. We use Consul to provide the runtime control plane for the data
tech.kayac.com Advent Calendar 2014 10日目担当の @fujiwara です。 最近書いている stretcher というデプロイツールの紹介をしたいと思います。 長いので3行で push型デプロイはホスト台数が増減しやすい環境に適さない 各種問題を解決するpull型デプロイツールを書いた Consul と連携するよ 中央ホスト配布(push)型デプロイの問題点 カヤックの自社サービスでは久しく Archer というツールを利用し、中央ホストから各デプロイ対象ホストに rsync でファイルを配布する形のデプロイを行っていました。ここではこれを push 型と呼びます。 push型のデプロイは、ホスト台数が頻繁に増減する環境で以下のような問題があります。 新しくホストが起動してきた場合に、中央ホストからデプロイを行ったあとでないと (古い状態で起動してい
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
9/5(日本は9/5)、サービス検出とイベントを管理する、Consul v0.4 がリリースされました。以下 Hashicorp の blog です。 Consul 0.4 – HashiCorp https://www.hashicorp.com/blog/consul-0-4.html 新機能が色々出てきました。Serfのeventと、リモート実行をサポート。event実行のタイミングはwatchで処理。ACLも実環境だと必用だし、着々と色々揃ってきた感があります。 今回、Serf の機能を内包したことで、Consul はオーケストレーションツールでもある、と言えるようになったのかなと思います。それにしても Hashicorp すごい(小並艦 Consul v0.4 is very cool! Its event and exec are very useful for me. I w
6月13日に Consul の最新版 v.0.3.0 がリリースされていました。いくつかの機能追加や、改善が図られています。以下、v.0.2 からの変更点と、v.0.4 のロードマップに向けたメモです。 てっきり、このブログに書いたと思って居たのですが、完全に私の思い違いでした。Qiita に投稿したつもりで、自己満足してしいたようです、気づきませんでした。。Qiita いいですよね。ブログに書き記すような重たいことじゃなくて、日々のメモを、マークダウンで手軽に書けるのは便利なところ。これはいいものだ。作った中の人、すごい。 さて、以下 ChangeLog の中を、日本語で軽く追っていきます。 ところで、Consul って何?という方は、先日資料を作りましたので、こちらをご覧ください (ご注文は自動化ですか? Serf と Consul を使って運用を楽しくする話 @ JTF2014)。
先日とあるサービスに Consul を入れました。 内部 DNS と、たとえば nginx からアプリケーションサーバに振り分ける定義をするために service を使用しています。 そこで使うために、ohai-plugin-consul を書きました。Github にあります。 fujiwara/ohai-plugin-consul · GitHub Ohai の version 6 と 7 で plugin の interface が変わっており、ohai-plugin-consul は Ohai 7 向けなので、Chefから使う場合は Chef-11.12.0 以上、または 11.10.4.ohai7.0 が必要です。 【参考】 Ohai, new Ohai plugins! - O'Reilly Radar 使用方法 ohai コマンドから使う場合は -d で plugin (co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く