なぜ多様な事業にコミットできるのか。「お知らせ通知UI/UX改修プロジェクト」に見るDMMの開発カルチャー
For customersCustomer supportSubscription managementSupport casesRed Hat Ecosystem CatalogFind a partnerFor partnersPartner portalPartner supportBecome a partner Try, buy, & sellRed Hat MarketplaceRed Hat StoreContact salesStart a trialLearning resourcesDocumentationTraining and certification Hybrid cloud learning hubInteractive labsLearning communityRed Hat TVOpen source communitiesGlobal advocac
最近話題のHashicorp社のconsulについてまとめたスライドです。特にdocker界隈で話題になっていますね。
はじめに KLabさんの協力会社として一緒にお仕事をさせて頂いておりますクラスターコンピューティングと申します。今回はSerfの同様にHashiCorpより提供されているConsulを試してみました。 コンテナによるクラスタなど随時サービスが追加削除されるような環境ではそのアドレスはDHCPなどにより動的に決定されます。コンテナ名などでそのサービスにアクセスできれば便利ですが、動的なアドレスとコンテナ名の関係をどのように解決するかという点が問題になります。クラスタ内でロードバランサやリバースプロキシ等を利用している場合、サービスの追加に応じてその設定ファイルも動的に更新しなくてはなりません。また、構成が随時変化するなかで、現在どのサービスがどのホストで実行されているかということを把握する必要もでてきます。 Consulを利用することによりこれらの問題を解決することができます。今回はそのため
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
注意 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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? そろそろ docker swarm を使ってのマシンプール(クラスタリング)作成を試してみようかとチャレンジしてみました。 世間にある記事を見ると docker machine でクラスタ作成して swarm も machine 経由で利用する例が多いのですが、敢えて machine を使わず直接 swarm の構築を行いたいというのが今回の目的となります。既に docker engine が稼働済みの環境を数台用意していて、そこに swarm を仕込む事で 1つの docker pool にします。 docker swarm の使い方
Consul のメジャー・アップデートがありました。Blog 記事があがっていましたので、例によって参考程度にどうぞ。 Consul 0.6 – HashiCorp https://hashicorp.com/blog/consul-0-6.html —-ここから ■ Consul 0.6 私たちは Consul 0.6 のリリースにワクワクしています。今回は多くの新機能や改良が追加されたメジャー・アップデートです。Consul とは最新のデータセンタ・ランタイムです(訳者注:HashiCorpでは、いわゆるネットワーク・システムのことをデータセンタとして表現しています。日本語の物理的なデータセンタとは概念が少し異なります)。Consul は扱いやすい Go 言語のバイナリであり、サービス・ディスカバリ、設定、オーケストレーションの各機能があります。分散と高い可用性、そして、複数のデータセ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Docker Engine 1.9 でついにマルチホスト間の仮想ネットワーク接続がサポートされました。 これで Docker を利用したクラスタシステム開発にさらに弾みがつくものと期待します。 Docker Engine 1.9 の仮想ネットワークを構築するためには Docker Engine だけでなくクラスタ対応の分散型KVSが必要で consul/etcd/ZooKeeper が対応しているとの事です。 この機会に consul を使ってみようというのが今回の起点となります。 consul でできること consul は Hash
Site Reliability Engineering Team(通称SRE)の@cubicdaiyaです。最近チーム名が変わりました。 今回はConsulを利用して複数台のnginxサーバのTLSセッションチケットを自動更新する仕組みについて紹介します。 TLSセッションチケットは簡単に言うとTLSのセッション情報を暗号化してクライアント側に保存することで HTTPS通信時に行われるTLSハンドシェイクの手順を省略してネットワークレイテンシを削減するための仕組みです。(詳細については一番下の参考情報を御覧ください) 似たような仕組みとしてTLSセッションキャッシュがありますが、こちらはセッション情報をサーバ側に保存します。 HTTPS通信ではTCPのハンドシェイクに加えてTLSのハンドシェイクが必要になるのでHTTP通信よりもネットワークのレイテンシが大きくなりますが、 これらの仕組み
Stretcher を使うと、Consul と連携して、所謂 Pull 型の Deploy ができるようになります。 Consul と連携させる場合は、 $ consul event -name deploy s3://xxx-stretcher-files/deploy-20151112-193139.yml のように、consul event で Manifest の path を指定してイベントを送ると、 YAML に書いてある path(s3, http, file) から tar.gz を取得して展開してくれます。 Stretcher は Rollback するのも簡単で、 Rollback したいバージョンの Manifest の path を指定して consul event を実行するだけです。 S3 に置いている場合、都度 aws s3 ls などして Manifest
tl;dr @inokara @matsumotory mruby界隈に名を轟かすチャンスです!— Uchio KONDO (@udzura) November 6, 2015 @inokara @udzura ウオオオ、楽しみです!— MATSUMOTO, Ryosuke (@matsumotory) November 6, 2015 上記のような振りを頂戴したので、mruby 界に名を轟かす為にもうすぐ初老を迎えるという勢いで Consul HTTP API の mruby クライアントを作り始めた。 github.com mgem-list への登録済み、尚、全てのエンドポイントはサポートしていない(引き続き追加していく予定)。 memo サポートしている Endpoint 現時点では以下の Endpoint をサポート。 Key/Value store Health checks
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で問い合わせする際にピリオド
タイトルの英語綴りが正しいか気になる。 tl;dr JMeter のクラスタ構成を Docker でなんとか出来ないかなと思ったら Docker Swarm というものがあるらしいのでチュートリアルしてみた。 Docker Swarm とは 参考 docs.docker.com イメージ Docker Swarm とは複数 Docker ホストをクラスタリングして個々の Docker エンジンを一つの Docker エンジンとして扱えるツール(という認識)で以下のようなイメージを頭に描いた。 チュートリアルしてみて上記のイメージは大体合っている気がしたが、実際に構築する場合には以下のように swarm クラスタ内には swarm manager という役割を持ったクラスタの master ノードが必要になる。 swarm manager となるノードについてはクラスタのオーケストレーション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く