Consulクラスタ全体が不安定になった事案と原因 - Qiita
環境 Consul Server(0.5.2) x 3 Consul Agent(0.5.2) x 数十台 現象 とある日、プロダクトのConsulクラスタ管理下のサーバがちょいちょいアラート出すので Consulログを確認するとノードが数分間隔で EventMemberFailed と EventMemberJoin を繰り返していた。 特に特定のノード、というわけでもなく、ランダムにノードがFailし、数十秒後にJoinし直す、というログがひっきりなしに出力されていた。 「consul flapping」でぐぐってみると、いくつか同じような現象で悩んでいる事案があるようだった。 原因となったサーバ ほぼ全てのノードがflapping状態だったので原因つかめず途方に暮れていたが、この投稿 で のfromのサーバを見るといいよ、とあったのでgrepしてみるとビンゴ。 そのサーバにログインし
supervisor管理下のデーモンに対して任意のシグナルを送信したい - Qiita
タイトルまま。 nginxなどもsupervisorで起動しているが、 ログローテーションするときにUSR1シグナル送りたい。 そんな時は以下のようなワンライナーでPIDを取得し、直接送信すれば良い。
DockerToolboxに移行した時のメモ - Qiita
※2015/08/29 追記 現在DockerToolboxでVirtualBoxも同時にインストールすると最新の5.0.2がインストールされますが このバージョンがDockerMachineと相性が悪く、VMが起動しないという罠があります。 https://github.com/docker/machine/issues/1716 VirtualBoxのバージョンを5.0.0に下げるか、 こちらから次期テストバージョンの5.0.3をインストールしましょう。 Docker1.8リリースと同時に DockerToolbox というものが公開された。 https://www.docker.com/toolbox 要するに、Dockerまわりの環境を全部入りしたインストーラ。 2015/8/14 時点では以下のツールが同梱されている。 Docker クライアント Docker Machine（D
EC2上からワンライナーでAWSアカウントIDを取得する - Qiita
curl -s http://169.254.169.254/latest/meta-data/iam/info | jq -r .InstanceProfileArn | awk -F: '/arn:aws:/{print $5}' Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
Docker Registry 2.0 を試す＋ 運用を考える - Qiita
http://qiita.com/spesnova/items/658a47e40eaea5b5a5f4 ほぼこちらの手順をv2.0に置き換えた版＋運用について＋パフォーマンス改善について書いてみました。 動機 Dockerプライベートレジストリが欲しくなった ウェブをみると、自前はつらいという話が多かったのでどのくらいつらいのか知りたかった Docker Registry運用方法について Docker Registry用のサーバは 持たない方針 で進める 持ってしまうと… 管理サーバが増える SPOFになる（冗長化考えるのめんどい） 認証考える必要ある つらい 個々のサーバにDokcer Registryコンテナを立てる方式を採用 かつバックエンドにs3を使う方式にすると、 インタフェースだけローカルのDocker Registryを通して S3上のDockerイメージを共有することが出
hubot-slack3.xがいつの間にかプライベートチャンネル対応してたので設定メモ - Qiita
久々にheroku上にいるhubotをデプロイしたら botが動かなくなってしまったので色々調べてたら slack <-> hubot 連携がバージョンアップしてたらしい。 そしてプライベートチャンネルでも普通にhubotが動くようになってた。 さらに、世に出ているSlackとHubotの設定記事 のようなものも 古いバージョンの設定が多いので 最新版という位置づけでここにメモしておく。 （2015/4/15時点） 手順まとめ Slack上の Hubot Integration を新バージョンにする hubot-slackを3.xにアップグレードする Herokuの環境変数を設定し直す hubotインテグレーションしたいチャンネルにhubotユーザをinviteする Slack上の Hubot Integration を作り直す ここからHubotインテグレーションの新規追加を行います（新
OpenRestyのre.matchとstring.matchの性能差 - Qiita
OpenRestyで正規表現を利用する場合、 高機能なre.matchを利用したくなりますが Lua純正のstring.matchと比較してどの程度性能に差があるのかを調べてみました。 環境 Dockerfileを公開しているので、こちらで再現できると思います。 サーバ EC2: t2.medium ベンチマークコマンド re.matchがOpenRestyのコアライブラリのため HTTP経由でベンチマークを取っています。 cというパラメータを付けると正規表現のループ回数を指定できます。
Chef-soloからItamaeに完全移行した話 - Qiita
※2016/04/24 追記 昨年末にItamae meetupで話した時のスライドリンクを追記しました。 Databag > itamae-secret の話やConsul連携の話が追加されています。 http://www.slideshare.net/tsuyoshitorii5/itamae-meetup-vol1public 現在自分が運用管理しているChef-soloプロビジョニングの仕組み 1 を Itamaeに移行した時のお話をしようと思います。 管理規模としては大規模ではなく、小〜中規模的なところかと思います。 （ロールによってレシピ切り分けたり、環境毎にレシピ用意したりなど…） 最初に: Itamaeについて https://github.com/itamae-kitchen/itamae 軽量なChef と考えればよいでしょう。 Chefの複雑さを取り除き、必要十分な部
consul-templateのイベント発火トリガーについて調査した - Qiita
ざっくり説明するとconsul-templateとは consulの様々なイベントを検知して 「テンプレート更新」 ＞ 「任意のコマンド実行」 してくれるツールです。 今回実現したかったのは consul-kvsの変更をトリガーにしてほげほげする ことです。 最初はconsul-templateがどういう条件でイベント発火するのかよくわからなかったのですが、 ドキュメントをよく見たらその辺りの仕様が記載されていたのでメモしておきます。 どういう条件でwatchしているのか？ 何の事はない話で、基本的には 読み込むテンプレート内で利用している値が変更されたかどうか を見ているようです。 素晴らしいですね。（※一部例外あり） 例: kvsのキーの値を監視する場合 以下のようなテンプレートで key を参照するだけでよいです。
Docker公式のmysqlイメージを使いつつ初期データも投入する - Qiita
メモです。 Docker公式のmysqlを使いつつ、初期データ投入するのに 少し手間取ったのでメモします （全部自前で書けばいいじゃん…というのは置いといて） ディレクトリ構造 ざっくりこんな感じを想定。 APP_ROOT/ app/ db/ setup.sql > create文とかinsert文とか fig.yml fig/ app/ Dockerfile mysql/ Dockerfile > ここから /app/db のSQLを使いたい ... やりたいこととしては、 app用とfig用のディレクトリがあって、 mysql用Dockerfileからapp用のディレクトリ配下にあるSQLファイルを使って 初期テーブル作ったりデータ投入したい。 実現している方法 fig/mysql/Dockerfile FROM mysql:5.6 # utf8サポート RUN { \ echo '[
VagrantでDockerが動く環境を一撃で作る - Qiita
メモです。 boot2dockerを使わず、 vagrant上に普通にVM立ててDocker使える環境を一撃で用意するコマンドです。 （VMはubuntu14.04） 一撃でインストール wget https://raw.githubusercontent.com/phusion/baseimage-docker/master/Vagrantfile && vagrant up vagrant ssh ... $ docker run busybox echo 'Hello Docker!' Unable to find image 'busybox:latest' locally df7546f9f060: Pull complete ea13149945cb: Pull complete 4986bf8c1536: Pull complete 511136ea3c5a: Already
Dockerコンテナと同期しつつ自動リロードさせている時の注意点 - Qiita
メモです。 こちら の記事でローカルPCとDockerコンテナのボリュームを同期しつつ、 スクリプトが更新されたらFlaskを自動リロードさせる仕組みを紹介しました。 pythonプロセスの負荷が上昇 現在は実際にこのスタイルで開発しているのですが 同期されるファイルが増えてくると Dockerコンテナ内のpythonプロセスの負荷が高くなってきていることに気付きました。 なんでかなーと思って調査したところ、 自動リロードの部分を削ると負荷が激減しました。 つまり自動リロードが悪さしている様子。 インターバルを増やす 監視インターバルの間隔を延ばすと多少負荷がマシになりました。 先のスクリプトの例では、オプションにインターバルを指定します。 ... if __name__ == "__main__": app.run(host="0.0.0.0", debug=True, reloader
Amazon EC2 Container Service プレビュー版で実践編をがんばってみた結果 - Qiita
仕様についてメモ １つのサーバは１つのクラスタにのみ属する。 １サーバ内では１つのタスクのみ実行できる。別のタスクを実行しようとするとタスクが上書きされる。 テスト構築しようとしていた構成 Appクラスタは webアプリ／fluentd／sensuクライアント の３つのコンテナで、 Redisクラスタは redis／sensuクライアント の２つのコンテナで、 Fluentdクラスタは fluentdサーバ（Appからの受信用）／sensuクライアント の２つのコンテナで、 Sensuクラスタは sensuサーバ（各サーバのモニタリング） の１つのコンテナで、 構成されています。 で、結論から言うと現時点ではムリ〜。 ダメな理由 プレビュー版制限事項 そもそも、プレビュー版の制限として クラスタは最大２つまで という縛りがあるため、上記構成は出来ませんでした。 http://docs.aw
AWS Lambdaをcronの代わりに使ってみるよ - Qiita
この記事は AWS Lambdaアドベントカレンダー １６日目の記事です。 概要 AWS Lambdaはイベント駆動で処理を実行する事ができます。 つまり 「何らかのイベント」＞「Lambda実行」＞「何らかのイベント」＞（繰り返し） と繰り返すことでcronの代わりに利用できないか？と考えました。 上手く行けばサーバレスであんな事やこんな事ができちゃうかもしれませんね…！ 今回試してみた構成 S3のイベントをトリガーにしてみました。 とあるファイルをトリガーにして、 その中身のフラグを見て 処理開始(0)／処理中(1)／処理終了(0/1以外) を判断しています。 また、cronのインターバルは最大でも60秒です。 これはlambdaのtimeout設定が 60秒までしか設定できない からです。 これより小さい数値でsetTimeoutすることにより、擬似ループのようなことを可能にしていま
Drone+fig でCIテストしてみる - Qiita
アプリケーションをfig化すると fig upするだけで同じ環境をすぐに構築することが出来ますよね。 つまり、CIでテストする環境もfig使うとそのまま動くのでは…と思い試してみました。 fig / Droneについてのref fig Docker1.3版 boot2docker+fig入門 Drone GitLab+DroneでHerokuにCIする、という最高の環境を10分で作る 構成概要 OSS版Droneを利用します。 Droneのscript内で普通にfigを実行し、 動的にDockerコンテナ起動した上でテストを実行しています。 Dockerコンテナは普通にDroneと同じく、ホストOS上にコンテナを起動しています。 サンプルプロジェクト https://github.com/toritori0318/drone-fig-ci-sample 上記は fig公式 のサンプルアプリ
Docker1.3版 boot2docker+fig入門 - Qiita
Docker1.3がリリースされましたね！ それに合わせて、周辺ツールがアップデートされていて とても便利になったと感じたので紹介してみます。 Docker/boot2docker Docker 1.3: signed images, process injection, security options, Mac shared directories boot2dockerでのVolume問題が解決しそう Virtual Box Guest Additionsをサポートしたことにより、 MacOS上のファイルとコンテナ内の同期が簡単になりました。 またDockerがexecコマンドをサポートしたことにより sshインストールなしでコンテナ内でコマンド実行することが出来ます。 でかい。 figは複数のDockerコンテナをお手軽に管理するためのツールです。 シンプルなyamlファイルを用意
NginxでリバースプロキシをKeepAliveしたときの性能検証 - Qiita
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Nginxでupstreamにhttpsなホストを設定する時の注意点 - Qiita
tigで別ブランチからcherry-pickする - Qiita
