多分あなたにKubernetesは必要ない | Yakst
trivago社の小規模な開発チームがコンテナオーケストレーターとしてKubernetesではなくNomadを採用することになった経緯と理由について、両プロダクトの特徴やユースケースに言及しつつ紹介されています。 [HashiCorp][Kubernetes]原文 Maybe You Don't Need Kubernetes (English) 原文著者 Matthias Endler 原文公開日 2019-03-21 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 2009日前 Twitterで報告済み 2008日前 原著者承諾済み 編集 スクーターに乗った女性（イラスト画像の作成元はfreepik、NomadロゴはHashiCorp） Kubernetesはコンテナオーケストレーションの巨人です。世界中で巨大なデプロイメントを動かしています
サービスメッシュについて調査してみた件 - Qiita
はじめに 最近、Kubernetesを中心としたコンテナ環境やマイクロサービスの文脈において、「サービスメッシュ」「Istio」というキーワードを聞く機会が増えています。 「Istio」は、2018/7/31にバージョン1.0に到達したことが発表され、ますます注目されるオープンソースソフトウェアとなっています。また、自分が所属しているSIerであっても、最近「サービスメッシュ」という言葉を聞く機会が増えてきています。 本記事では、サービスメッシュの概要から、サービスメッシュを実現するソフトウェアについて、Web上の情報などを元に調査した内容を整理したいと思います。 サービスメッシュとは マイクロサービスの課題 サービスメッシュの説明をする前に、サービスメッシュの前提となるマイクロサービスにおいて、どのような課題が存在するか整理したいと思います。 Service Discovery（サービス
VaultとConsulを連携する (1) Consulをstorage backendとして使う - Qiita
Vaultって何？ VaultはHashicorpが発表した機密情報管理ツールである。 詳細はいくらか日本語情報があるのでそちらを参照のこと。 http://pocketstudio.jp/log3/2015/04/29/vault/ http://kiririmode.hatenablog.jp/entry/20150429/1430279218 今回やること VaultはConsulをstorage backendにすることによりHA構成を取ることができる、とドキュメントに書いてあったので試してみることにした。 今回、VaultサーバとなるコンピュータはConsulクライアントでもあることとする。 これは設定ファイルでConsulのアドレスを指定する箇所だけに影響する。 Vaultサーバは2台立てることにする。 10.0.2.167(hostname: cc6)はCentOS 6、10
Consul | Pocketstudio.jp log3
Consul 0.5 がリリースされました。久々のメジャー・アップデートです。新機能や変更点がまとめられた内容が、HashiCorp のブログに投稿されました。例によって、自分の情報整理用の翻訳であり、死蔵しておくのもア…
Consul関連ドキュメント(参考訳)Part3 | Pocketstudio.jp log3
Consul v.0.3.0 のリリースにより、いくつか新機能に関するドキュメントが追加されていました。主に、セッションの管理と、DNS の TTL 、そしてリーダー選出に関するドキュメントです。 例によって、手許に簡単に翻訳したものがあるのですが、このまま眠らせておくのも勿体ないかと思い、公開します。なお、あくまで自分のメモの共有であり、内容は参考程度、未保証ということでお願いします。 ■Sessions – Consul http://www.consul.io/docs/internals/sessions.html Consul は分散ロックを構築するために、セッション機構を提供します。セッションは、ノード、ヘルスチェック、key/value データそれぞれのレイヤ間を結びつける働きをします。セッションは granular（グラニュラー）ロッキングを行えるよう設計されており、The
Consul関連ドキュメント(参考訳)Part2 | Pocketstudio.jp log3
前回に引き続き、Consul 関連ドキュメント ( http://consul.io/ ) の参考訳です。 内容は、Consul エージェントについて、DNS インターフェース、HTTP API、service と check の定義について。 ■ CONSUL エージェント http://www.consul.io/docs/agent/basics.html Consul エージェントは、Consul の中核となるプロセスです。エージェントはメンバーシップ情報を保持し、サービス情報の登録や、チェックの実行、クエリに対する回答や、その他の動作をします。Consul クラスタに含まれる全てのノードで、このノードを動作させなくてはいけません。 エージェントは、クライアントかサーバか、いずれかの状態で動作します。サーバノードでは、クォーラム・コンセンサス（総意）形成の一部となるため、追加の義務
Consul関連文書の参考訳、Serfとの違い等 | Pocketstudio.jp log3
Consul について、自分の中の理解を深めるために関連ドキュメントの参考訳を作成しました(4/19現在)。せっかく作ったのに、自分の引き出しの中にしまっておくだけでは勿体ないと思い、公開します。Consul や Serf に興味を持っている方の参考になれば幸いです。 Consul の意味は、’領事’や’執政官’です。Serf は’農奴’ ですから、まるで、農民(Serf)を支配し、使役するお代官様(Consul)のような関係がイメージされます。実際のところ、Consul は内部の Serf クラスタ上に構築されていますが、Consul の機能や役割は、Serf の持つものとは異なるように見えます（現時点の公開情報では）。詳しくは、ドキュメントをご確認ください。 実際に使いたい！という場合は、先日の投稿 Consul を使ってみた、をご覧下さい。 当ページのドキュメントについては、あくまで
公式の consul イメージで高可用性 Consul クラスタを試す - Qiita
# create machines (consul0, consul1, consul2) for i in 0 1 2; do docker-machine create -d virtualbox --virtualbox-memory 512 consul$i done # start consul servers for i in 0 1 2; do docker $(docker-machine config consul$i) run \ -d \ --name consul$i \ -p 8300-8302:8300-8302/tcp \ -p 8301-8302:8301-8302/udp \ -p 8400:8400/tcp \ -p 8500:8500/tcp \ -p 8600:8600/tcp \ -p 8600:8600/udp \ consul agent \
DockerコンテナをConsulで管理する方法 - Qiita
はじめに Dockerを利用するとコンテナをぽこぽこ沢山立てることが多いと思います。 コンテナが沢山できるので、それらに対していかに効率よくアクセス出来るかが肝になります。 またコンテナで提供するサービスのポートをホストに割り当てて利用する場合(-pオプションを利用する場合)、 ポコポコ出来るコンテナのポートを静的に(-p 80:8080みたいに)割り当てるのは面倒です。 なので動的に(-p 80みたいにしてホストの適当なポートに)割り当てたいところです。 ただし、動的に割り当てるとどのコンテナがどのポートでサービスを提供しているか把握するのが難しくなり、さらにマルチホストになるとどのホストで動いているかどうかを把握する必要もあり、これも難しいです。 この辺うまいこと出来ないかな、ということでServiceDiscoveryといったらConsulですよねってことで組み合わせて使ってみます。
Consulを頑張って理解する
9. 大雑把な構成イメージ ※色々省略してます node01.example.jp IP：192.168.20.21 consul server 01 node04.example.jp IP：192.168.20.41 consul client 01 apach01 node02.example.jp IP：192.168.20.22 consul server 02 node03.example.jp IP：192.168.20.23 consul server 03 node05.example.jp IP：192.168.20.42 consul client 02 apach02 consul操作script等 consul操作script等 consulクライアントで自身のノー ドにあるApacheの状態を監視 Apacheで実行されているWeb アプリをサービスとして co
Consulのおもしろそうな仕組みについて調べてみました : DSAS開発者の部屋
はじめに KLabさんの協力会社として一緒にお仕事をさせて頂いておりますクラスターコンピューティングと申します。今回はSerfの同様にHashiCorpより提供されているConsulを試してみました。 コンテナによるクラスタなど随時サービスが追加削除されるような環境ではそのアドレスはDHCPなどにより動的に決定されます。コンテナ名などでそのサービスにアクセスできれば便利ですが、動的なアドレスとコンテナ名の関係をどのように解決するかという点が問題になります。クラスタ内でロードバランサやリバースプロキシ等を利用している場合、サービスの追加に応じてその設定ファイルも動的に更新しなくてはなりません。また、構成が随時変化するなかで、現在どのサービスがどのホストで実行されているかということを把握する必要もでてきます。 Consulを利用することによりこれらの問題を解決することができます。今回はそのため
Consulクラスタ内でファイルを分散配布する tuggle を書いた - 酒日記 はてな支店
github.com これはなに? HTTPを使って、ファイルを Consul クラスタ内で分散配布する daemon です。Go で書かれています。読みかたは「たぐる」です。 開発動機とユースケース 拙作の Stretcher というデプロイツールがあります。嬉しいことに、自分が勤務しているカヤックだけではなく、他社さんでも使われているようです。 先日、某社の Stretcher をお使いのかたに話を伺う機会があり、デプロイアーカイブの取得時のネットワーク負荷が問題になっているということを聞きました。 カヤックではサーバは基本 AWS にあり、S3 からデプロイアーカイブ(200〜300MB程度)を取得しています。S3はちょっと意味が分からないぐらい堅牢で、stretcherの -random-delay 5 (開始を平均2.5秒、最大5秒ずらす) を設定した状態で100台程度から一斉に
TLS認証なDocker Swarmクラスタを構築 (docker-machineなしで) - Namiking.net
備考 swarm-node0はマスターノードとして使う ホスト名(hostname)は別になんでもよい プライベートネットワークを有効にしておく eth0はグローバルネットワークに繋がるインタフェース eth1はプライベートネットワークに繋がるインタフェース 各ノードでConsulを動かす Swarmクラスタのサービスディスカバリー(分散KVS)であるConsulを各ノードにインストールする。使わないでもSwarmクラスタは構築できるが、マルチホスト間でオーバーレイ・ネットワークを作れるようになったりと色々利点が多いので。(etcdやZookeeperでも構築可能) swarm-node0にてConsulをサーバーモードで動かす SSHでログインして作業を行う。 インストール # 必要なパッケージのインストール apt-get install -y curl zip # Consulインス
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
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
Lobiのログ集約・解析のはなし - KAYAC engineers' blog
Lobiチームの長田です。 あらゆるWebサービスがそうであるように、Lobiでも日々大量のログが出力されています。 今回はこのログをどのように集約・解析しているかを紹介します。 TL;DR アクセスログ・アプリログなど、毎秒10000行以上のログが生成されている Fluentdを使用しログを集約 consul serviceを利用した集約サーバーの冗長化 ログ中のイベント検知・集約にはNorikraを使用 アクセスログの各種解析にはAmazon Redshiftを利用 ログの集約 ログ収集エージェント Lobiではログの集約にFluentdを利用しています。 Fluentd | Open Source Data Collector | Unified Logging Layer ログファイルの集約にはfluent-agent-hydraを、Perlアプリケーション内からのログ送信にはFl
mhaとconsulでDBサーバーの冗長化をしています | feedforce Engineers' blog
こんにちは。Lorentzcaです。3月ですがまだまだ寒いのでなかなか釣りに行けずテンションさげぽよです！ ↑↑ この度DBサーバー(物理マシン、MySQL)の引っ越しを行いました。 そのついでに、冗長化の仕組みをmhaとconsulを使った方法に変えたので紹介します。 はじめに まずは簡単に引っ越し前と引っ越し後の構成を比べてみます。 引っ越し前は以下の様な構成でした。 サーバー台数: 2台 MySQLフェイルオーバーの仕組み: 自作シェルスクリプト アプリの参照先を切り替える仕組み: keepalivedでvipを張り替えることで実現 引っ越し後は以下の様な構成になりました。 サーバー台数: 3台 MySQLフェイルオーバーの仕組み: mha アプリの参照先を切り替える仕組み: consulのdns機能を使って実現 なぜこのような構成にしたのか、話していきます。 引っ越し前に持っていた
Coordination Service(ZooKeeper，etcd ，consul) の比較
概要 最近，consul，etcd，ZooKeeper といった，いわゆる Coordination Service(この名前は ZooKeeper の論文から拝借した)の実装が頻繁に行われている．本記事では，開発が盛んな背景を踏まえた上で，オープンソース実装の Coordination Service の比較を行う． Chubby から現在まで Paxos が Google の手によって Chubby という形で実用化された後，故障検出+分散合意アルゴリズムを用いた高可用KVSという組み合わせによる Coordination Service のオープンソース実装がいくつが出てきた．そのはしりが ZooKeeper である．ZooKeeper は Hadoop ファミリではデファクトスタンダードの Coordination Service であり，Hadoop を初めとして HBase，M
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
Redirecting…
