こんにちは、つるべーです！みなさん、Consul使ってますか？ ConsulはHashiCorpが開発するツールで、サービスディスカバリやヘルスチェックなど様々な機能を有しています。Consulは、ノードやサービスの状態変化を起点として、特定の処理を発火させることができるため、『状態の把握 → 変化の検知 → 動的な制御』のような流れがConsulを使って組むことができ、動的に変化するインフラの運用管理に絶大な力を発揮するツールです。 一方で、その多岐にわたる機能のため、仕組みを完全に把握することが難しく、使い方によっては思わぬ危険性を持ってしまうことがあります。今回は、Consulのセキュリティ対策について、ACLという仕組みを中心に書いていきたいと思います。 目次 セキュリティ対策の概要 Consul HTTP APIに内在する危険性 HTTP APIへのセキュリティ対策 1. HTT
最近、5kgの重しを背負って懸垂していますプリンシパルエンジニアの @linyows です。 みなさん、NHKの「筋肉は裏切らない！」（正しくは筋肉体操）見てますか？ … はい。ですよね。 GMOペパボは、ロリポップ！やminneなど様々なサービス（microservices的なものではない）を運営しており、それぞれにおいて、秘密情報を管理している状態にあります。この秘密情報を独自に管理するのは、専門のスキルやノウハウとしてあらゆるコストがかかります。 そこで僕（ら）は、秘密情報管理ソフトウェアであるHashiCorp Vaultを各サービスに導入し、サービスを堅牢にするというゴールをもとに社内でVaultのWorkshopを幾度となく開催しています。 今回は、そのWorkshop「やわらかVault」のご紹介です。 やわらかVault これは、HashiCorp Vaultを正しく理解し
PackerBuild and manage images as code
With so many new technologies coming out every year (like Kubernetes or Habitat), it’s easy to become so entangled in our excitement about the future that we forget to pay homage to the tools that have been quietly supporting our production environments. One such tool we've been using at Stripe for several years now is Consul. Consul helps discover services (that is, it helps us navigate the thous
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
Consul Casual Talks #1 http://connpass.com/event/35836/
Consul を利用して構成されたクラスタの各ノードにアプリケーションコンテンツ（ソースコード）を配布するデプロイツール stretcher というツールを教えて頂いたので試してみた。 github.com tech.kayac.com stretcher の詳細については上記の GitHub リポジトリ又は以下の紹介記事をご一読あれ。m(__)m とは言っても、stretcher について自分なりに纏めてみた stretcher が行うこと デプロイの手順が記された YAML ファイル（以下、マニフェスト）を取得 マニフェストに記載されたソースリポジトリよりアプリリケーションコンテンツ（ソースコード）を取得して展開 展開したファイルを rsync を利用してターゲットディレクトリに転送（rsync は --delete オプション） 以降はマニフェストに記述されたコマンドを実行する（アプ
こんにちは。Lorentzcaです。3月ですがまだまだ寒いのでなかなか釣りに行けずテンションさげぽよです！ ↑↑ この度DBサーバー(物理マシン、MySQL)の引っ越しを行いました。 そのついでに、冗長化の仕組みをmhaとconsulを使った方法に変えたので紹介します。 はじめに まずは簡単に引っ越し前と引っ越し後の構成を比べてみます。 引っ越し前は以下の様な構成でした。 サーバー台数: 2台 MySQLフェイルオーバーの仕組み: 自作シェルスクリプト アプリの参照先を切り替える仕組み: keepalivedでvipを張り替えることで実現 引っ越し後は以下の様な構成になりました。 サーバー台数: 3台 MySQLフェイルオーバーの仕組み: mha アプリの参照先を切り替える仕組み: consulのdns機能を使って実現 なぜこのような構成にしたのか、話していきます。 引っ越し前に持っていた
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 やトラフィックの上限が非常に高いストレージがある)でデプロイを速くしたいという場合は、それらを使えばよろしいかと。
次世代システム研究室 2015 年 4Q の研究発表会にて発表しました。 HashiCorp の新ツール “Otto” に関する調査結果の紹介です。
PackerBuild and manage images as code
Site Reliability Engineering Team（通称SRE）の@cubicdaiyaです。最近チーム名が変わりました。 今回はConsulを利用して複数台のnginxサーバのTLSセッションチケットを自動更新する仕組みについて紹介します。 TLSセッションチケットは簡単に言うとTLSのセッション情報を暗号化してクライアント側に保存することで HTTPS通信時に行われるTLSハンドシェイクの手順を省略してネットワークレイテンシを削減するための仕組みです。(詳細については一番下の参考情報を御覧ください) 似たような仕組みとしてTLSセッションキャッシュがありますが、こちらはセッション情報をサーバ側に保存します。 HTTPS通信ではTCPのハンドシェイクに加えてTLSのハンドシェイクが必要になるのでHTTP通信よりもネットワークのレイテンシが大きくなりますが、 これらの仕組み
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
From release 1.6.1 onward, the minimum golang version supported is 1.16. From release 1.6.0 onward, metrics backend statsd is no longer supported. statsd_raw works similarly, though it actually resets counters appropriately. If you are using datadog, you should consider using the new dogstatsd backend, which has support for tags now. Graphite histogram functionality has changed slightly since swit
■ rails の pull 型デプロイへの質問 昨日の発表直後は時間がなくて質問への受け答えがあまりできなかったんですが、発表後にぶらぶらしていた時にもらった質問が鋭い内容だったので紹介します。 No SSH ポリシーは反発もでたり、チームへの浸透は難しいのではないか minne チームは選任のインフラエンジニアがおらず、アプリケーションの開発チームが兼務してインフラを作っていたので、コードでインフラを作るというのはすんなりと受け入れられた(と思う) pull 型デプロイだと、更新漏れが起こったり、あるサーバーだけが調子わるくてデプロイが失敗したということが起こった時の検知が難しいと思うんですがどうやってますか その通りで問題は把握しているがまだ具体的な解決策は作れてない状態。デプロイ後にコードのリビジョンなどを kvs に突っ込んで、サーバーすべてが更新されたことを検知してアラート、と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く