Dockerを使って軽くConsulを触ってみる | さくらのナレッジ
サーバ界隈の技術革新が激しい今日この頃ですが、名前は知っていつつもなかなか触る機会がないなんて状態ではないでしょうか。特に複数台のサーバを予め用意しなければならないソフトウェアは準備だけでも大変で、なかなか手出ししづらいかと思います。 そこで使ってみたいのがDockerです。Dockerを使うことで1台のサーバでも仮想的に複数台サーバ構成を試すことができます。今回は最近登場したConsulをDocker上で簡単に試してみたいと思います。あくまでも触れる程度なので、本格的な運用とは別でお考えください。 サーバを立てる さくらのクラウドを使ってサーバを準備します。OSはCoreOSになります。サーバの追加を行う際にアーカイブ選択で CoreOS 367.1.0 (stable) #112600559854 を選択します。 サーバ追加画面。アーカイブからCoreOSを選びます。 CoreOSに接
Consulクラスタ内でファイルを分散配布する tuggle を書いた - 酒日記 はてな支店
github.com これはなに? HTTPを使って、ファイルを Consul クラスタ内で分散配布する daemon です。Go で書かれています。読みかたは「たぐる」です。 開発動機とユースケース 拙作の Stretcher というデプロイツールがあります。嬉しいことに、自分が勤務しているカヤックだけではなく、他社さんでも使われているようです。 先日、某社の Stretcher をお使いのかたに話を伺う機会があり、デプロイアーカイブの取得時のネットワーク負荷が問題になっているということを聞きました。 カヤックではサーバは基本 AWS にあり、S3 からデプロイアーカイブ(200〜300MB程度)を取得しています。S3はちょっと意味が分からないぐらい堅牢で、stretcherの -random-delay 5 (開始を平均2.5秒、最大5秒ずらす) を設定した状態で100台程度から一斉に
Consulのおもしろそうな仕組みについて調べてみました : DSAS開発者の部屋
はじめに KLabさんの協力会社として一緒にお仕事をさせて頂いておりますクラスターコンピューティングと申します。今回はSerfの同様にHashiCorpより提供されているConsulを試してみました。 コンテナによるクラスタなど随時サービスが追加削除されるような環境ではそのアドレスはDHCPなどにより動的に決定されます。コンテナ名などでそのサービスにアクセスできれば便利ですが、動的なアドレスとコンテナ名の関係をどのように解決するかという点が問題になります。クラスタ内でロードバランサやリバースプロキシ等を利用している場合、サービスの追加に応じてその設定ファイルも動的に更新しなくてはなりません。また、構成が随時変化するなかで、現在どのサービスがどのホストで実行されているかということを把握する必要もでてきます。 Consulを利用することによりこれらの問題を解決することができます。今回はそのため
ConsulのDNSを使ってRedisの冗長化 | サムテック！
こんにちはエンジニアのYです。 今回はConsulのDNSを使ってRedisの冗長化を検討しましたというお話です。 このような境遇の方は役に立つかもしれません。 Consulとは？ HashiCorp社のプロダクトの一つで管理対象のServerに仕込んで使います。下記の様な機能があります。 Service Discovery Failure Detection Key/Value Storage etc 例えばこんなことに使えます。 Service Discovery 起動しているServer(WEB,DB,Redis…)の一覧を出したいときなど Failure Detection NAT用のインスタンスを冗長化・負荷分散したい、障害が発生したらクラスタから切り離したいときなど Key/Value Storage オートスケールのためにリリースされてるアプリケーションのVersionを保持
WildFly Swarm＋Consul（＋Dnsmasq）でService Discovery - CLOVER🍀
WildFly Swarmには、Service Discoveryのための仕組みとしてTopologyがありますが、その実装手段としていくつかの 方法を提供しています。 Topology 今回は、Consulを試してみようかなと思います。 Topology using Hashicorp Consul Consul？ Consulというのは、HashiCoprの提供するService Discoveryの仕組みです。 Consul Introduction To Consul 主に以下のような機能を持ちます。 Service Discovery Health Check KVS Consul自体はAgentとして各サーバーで動作させるものですが、動作タイプにServerとClientがあり、通常は Serverは（データセンターあたり）3台または5台での構成を推奨しています。 Bootst
本番環境にも使える高可用性かつスケーラブルな Docker Swarm + Consul クラスタを構築 - Qiita
注意 UPDATED: 2017/02/07 この記事で説明しているクラスタは古い手法です。 本稿の内容で構築したクラスタでは docker service などの Swarm mode で導入されたコマンドが動作しません。 Docker 1.12 以降、 Swarm mode に DNS, LB が組み込まれており、外部のディスカバリサービス (Consul などの KVS) に依存しなくなりました。 Swarm mode は標準コマンド docker swarm でセットアップ可能なため、 docker-machine ssh でクラスタを構築できそうです。近日中に記事として公開予定です。 書きました → Swarm mode クラスタを構築して動かしてみる | Qiita TL;DR コマンド見れば分かる人向けの完成品はこちら → hidekuro/swarm-cluster-sam
Chef, Ansible, Consul, … 自働化ツールとその組み合わせ方
オープンソースカンファレンス2015 .Enterprise https://www.ospn.jp/osc2015.enterprise/Read less
Docker swarm のクラスタを network overlay 付きで構築する - Qiita
前回の「Docker swarm のクラスタを手で構築してみる」という記事の続編となります。 記述時の環境 docker engine - 1.11 docker swarm - 1.2.0 consul - 0.6.0 host - Debian 8.4 docker engine は get.docker.com を使ってのインストール ベースとなる VM イメージ クラウドで Docker コンテナを利用するために、予め環境を整えておいた Docker ホスト VM イメージを用意して使っています。swarm クラスタを作るために、この Docker ホストイメージからインスタンスを複数作成して swarm master と swarm node に仕上げます。 ベースイメージは以下の様な構成となっています。 Linux OS Debian 8.4 Docker engine con
LobiにおけるConsul活用事例 - KAYAC engineers' blog
Lobiチームの長田です。 今回はConsulのLobiにおける活用事例を紹介します。 Consulとは https://www.consul.io/ HashiCorp社が公開している、複数ホストを管理するために必要な機能が盛り込まれたツールです。 公式サイトには以下のように書かれています(意訳): Service Discovery サービスの登録とDNSまたはHTTPインターフェイスを用いたサービスの特定。 SaaSのような外部サービスも登録することができる。 Health Checking オペレーターがクラスタ内で問題があったことを素早く知ることができる。 Service DiscoveryはHealth Checkingと連動し、 問題のあるホストがサービス特定の対象になることはない。 Key/Value Storage 動的な設定・フラグなどをを保持するための柔軟なkey/v
Prometheus meets Consul -- Consul Casual Talks
Satoshi Suzuki gave a presentation on integrating Consul and Prometheus. He discussed Consul's ACL system for restricting access and the need to configure permissions for the anonymous token. He explained Prometheus is a monitoring system that pulls metrics and has native integration with Consul using Consul service discovery configurations. The integration allows Prometheus to retrieve scrape tar
Consul in Production
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
Consul by HashiCorp ～サービス・ディスカバリ入門～ - Qiita
誰？ Masahito Zembutsu @zembutsu (個人用) とある会社の Technology Evangelist (仕事) HashiCorp や Docker のドキュメント翻訳や技術検証 https://pocketstudio.net http://docs.docker.jp 過去の発表スライド http://www.slideshare.net/zembutsu Topics HashiCorp Consul 概要 開発背景 アーキテクチャ Consul でサービス登録 Consul Template 会社設立は 2012 年 Mitchell Hashimoto 氏と Armon Dadger データセンタ管理に革命をもたらすこと 設計思想は The tao of HashiCorp（Workflows, not Technologies やインフラのコード化
Building Blue-Green Deployment with Docker
Blue-Green Deployment is a strategy to release new version of the app without downtime. The basic idea behind this technique involves using two identical production environments, named Blue and Green. At any time, only one of these environment is live and serving the production traffic. The other one is used to test newer version or for roll-back. Let us assume that the current live production env
mhaとconsulでDBサーバーの冗長化をしています | feedforce Engineers' blog
こんにちは。Lorentzcaです。3月ですがまだまだ寒いのでなかなか釣りに行けずテンションさげぽよです！ ↑↑ この度DBサーバー(物理マシン、MySQL)の引っ越しを行いました。 そのついでに、冗長化の仕組みをmhaとconsulを使った方法に変えたので紹介します。 はじめに まずは簡単に引っ越し前と引っ越し後の構成を比べてみます。 引っ越し前は以下の様な構成でした。 サーバー台数: 2台 MySQLフェイルオーバーの仕組み: 自作シェルスクリプト アプリの参照先を切り替える仕組み: keepalivedでvipを張り替えることで実現 引っ越し後は以下の様な構成になりました。 サーバー台数: 3台 MySQLフェイルオーバーの仕組み: mha アプリの参照先を切り替える仕組み: consulのdns機能を使って実現 なぜこのような構成にしたのか、話していきます。 引っ越し前に持っていた
Consul クラスタ上で動作する S3 非依存の pull 型デプロイツール "fireap" を作った - weblog of key_amb
github.com fireap = fire + reap です。 Consul Event を発火(fire)して、受信側でそれを収穫(reap)する、という意で。 読み方は「ファイリープ」で良いかと思ってます。 どんなツール？ GitHub に上げた README.md より、かいつまんで日本語に変換しつつ説明します。 ノード数 N に対して O(log N) で動作するデプロイツールです。 が、実際にはデプロイに限らず任意のコマンドを実行できるので、README の中ではデプロイツールとは書いておらず、「高速タスクランナー」としています。 fujiwara/stretcher や sorah/mamiya は O(1) なので、それらが使える環境(S3 的な I/O やトラフィックの上限が非常に高いストレージがある)でデプロイを速くしたいという場合は、それらを使えばよろしいかと。
Ansible 2.0 から使えるようになった consul モジュールを試してみた - 無印吉澤
Ansible 2.0 になって使えるモジュールが大幅に増えましたが、その中に Consul 関係のモジュールがいくつかあります。前から気になってたので、ちょっと試してみました。 今回のお試し環境 ホストOS OS X Yosemite 10.10.5 VirtualBox 5.0.10 Vagrant 1.8.1 Ansible 2.0.1 ゲストOS CentOS 7.2 Playbook 昨年末に Web サーバ1台、MariaDB サーバ1台、Cloudera QuickStart VM で Consul クラスタを組む playbook を作ったので、今回はこれを使いました。 consul モジュールの検証に使った playbook muziyoshiz/hashicorp-sample: Sample configurations of HashiCorp tools vagr
Docker マルチホストネットワーキング: swarm, consul, overlay network(VXLAN) を使用した構築手順 - Qiita
Docker マルチホストネットワーキング: swarm, consul, overlay network(VXLAN) を使用した構築手順DebianUbuntuDockerconsulDockerSwarm Docker multi host ネットワーク 今までDocker の--link 機能を使うことで、同一ホスト内のコンテナの名前解決をして同一ネットワークのコンテナに対してアクセスすることは可能でしたが、それが複数の異なるDocker ホストになると--link 機能では実現することができませんでした。 そこでDocker のmulti ホストネットワーク及びDocker overlay ネットワークの機能を使用することで異なるホスト上にあるコンテナに対して、あたかも同じネットワーク上に存在しているコンテナのように、便利にアクセスすることができるようになります。 この機能を使う
Consulについてまとめてみた（基本編） - tjinjin's blog
About 最近Consulを使い始めたので、基本的な所をまとめてみます。 Consulとは 読み方は”コンスル”が正しいらしいです。でも”コンサル”って呼んでます← 公式HPを見ると、 Service discovery and configuration made easy. Distributed, highly available, and datacenter-aware. ﾄﾉｺﾄ 簡単に言うと、クラスタを組んでいろいろいい感じにできるツールという所でしょうか。 Consulでできること（一部） クラスタを組んでいるサーバ内で同じ情報を参照することができる（内部DNSやKey/Valueストアとして） ヘルスチェックに失敗したサーバを自動で切り離すことができる DBで言うところのMasterが死んだ時のfailover機能が実装されていて、細かい設定が要らない 各サーバ内でコマ
Consulがたまに暴れている件について - Qiita
現象について 日に１、２回ほどこんなログが出力される。 どこか（不確定）のノードが一時的にFailし、すぐにJoinし直す。 現象としては 以前 に書いたのと似てはいるが、頻度が低い。たまに起こる程度。 2015/11/30 06:09:25 [INFO] memberlist: Marking hogenode as failed, suspect timeout reached 2015/11/30 06:09:25 [INFO] serf: EventMemberFailed: hogenode xxx.xxx.xxx.xxx 2015/11/30 06:09:25 [INFO] consul: member 'hogenode' failed, marking health critical 2015/11/30 06:09:27 [INFO] serf: EventMemberJ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mesos consulで構築するマイクロサービスインフラ
