bashrc 内で bind を使うとリモートからコマンド実行時に警告が出る - weblog of key_amb
peco などを快適に使うために ~/.bashrc 内で bind コマンド*1を使って、キーバインドをカスタマイズしています。 このとき ssh $host "コマンド" のようにリモートからコマンドを実行すると、 ~/.bashrc から bind を実行する行で、下のような警告が出ます: /home/key-amb/.bashrc: line 30: bind: warning: line editing not enabled 解決策 この警告は TTY が有効でないことに由来するようです。 例えば、下のスレッドに回答があります: http://superuser.com/questions/892658/remote-ssh-commands-bash-bind-warning-line-editing-not-enabled?answertab=votes#tab-top 自
ssh と rsync だけで Tree Deploy を実現する "grifork" を作った - weblog of key_amb
はじめに〜fireap to grifork Tree Deploy とは grifork: standalone モード grifork: grifork モード 使い方 動作例と実行ログ 今後の展望 余談〜デプロイの未来について おまけ〜grifork の語源 はじめに〜fireap to grifork 約半年前に fireap というデプロイツール(タスクランナー)を作りました。 オンプレミスでも使えて、ノード数 N に対して O(log N) で動作する、というものです。 が、前提条件として、システム内の全ホストに fireap をデプロイし、また、全ホストで Consul の agent を動かす必要があります。 その辺りが導入障壁になる環境もあるかもしれないな、と思いました。 …で、少し工夫すれば、「デプロイサーバにだけプログラムがあればツリー状にデプロイできる」ものも作れる
時系列DBって結局どれがいいんだっけ #TSDB - weblog of key_amb
※4/6 その後調べた情報などを記事末尾に追記 前提となるニーズ サーバの負荷情報とか、アクセス状況のような KPI を取得・保存し、可視化(参照してグラフ化)したい。 リアルタイム性が要求される。5分以上前のデータしか見れませんみたいなのはお呼びでない。 古いデータはそんなに精度は気にしないけど、ロングスパンで俯瞰して見れたら便利。 最近はビッグデータ環境の時系列データ解析もビジネスではけっこうニーズがありそうだけど、そっちはもう少し要求が多そう。 ここでは考えないことにする。 選択肢になりそうなもの 古きよき RRDtool Elasticsearch + Kibana Graphite + Grafana InfluxDB + Grafana 等 Zabbix 他に、現実的には SaaS に任せるという手段もあるだろうけど、そう言うと話が終わってしまいそうなので、ここでは考えないこと
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 やトラフィックの上限が非常に高いストレージがある)でデプロイを速くしたいという場合は、それらを使えばよろしいかと。
コンテナ型仮想化のメリット・デメリット - weblog of key_amb
サーバインフラ運用の観点から。 メリット 起動が高速なので急な負荷上昇時に迅速にスケールアウトでき、機動的なキャパシティ制御(リソース管理)が可能。ピーク負荷に備えておくために、余分に起動しておくということが不要になり得る。 ただし、コンテナを載せるホストには常に余剰リソースが必要。 ローリングリスタートの仕組みが整えばデプロイがより安全になり、楽になり得る。再起動に伴う性能劣化やサービス停止の考慮が不要になるため。 アプリケーションに応じて graceful restart の仕組みを整えるという手間がなくなり得る。 OS やパッケージの更新がより簡単に実施できるようになる可能性がある。 コンテナ側の更新の容易さについては、上記で説明がついていると思う。 ホスト側の更新もより楽になりそう。 理由1) コンテナを別ホストに引っ越すことが簡単にできるシステム構成になるはず。 理由2) ホスト
Shibuya Perl Mongers テクニカルトーク #17 に参加して #shibuyapm - weblog of key_amb
6/2 に開催された Shibuya Perl Mongers テクニカルトーク #17 に参加してきました。 自分は初参加だったのですが、なんと前回開催から4年ぶりの開催とのこと。 「もうみんな Perl なんて書いてませんよね」というアイロニーな雰囲気が漂いつつも、「やっぱり Perl 書いてる」という人もたぶん 40% 以上ぐらいはいて、LT の盛り上がり具合から見てもみんな Perl が好きなんだなと感じるひとときでした。 以下、セッションの内容になります。 一部資料はネットにアップされているようです。 観測範囲で捕捉したものは、順次本記事にも追加していきます。 例によって愚直にメモを取っていたら、かなりの分量になってしまったのですが、あまり削ったりせずに、ほぼそのまま上げておきます。 開会の挨拶 @takesako さん 前回 - 正規表現祭り 2011/7月 shibuya.p
#HashiCode #1 HashiCorp 道場に入門してきました - weblog of key_amb
今週も秋葉原のクリエーションラインさんのオフィスにお邪魔してきました。*1 今回は「HashiCorp道場〜入門編〜」ということで、HashiCorp 製品ラインナップの Overview と各製品の機能概要、既存の同種のツールとの比較について講演がありました。 HashiCorp 製品はいろいろと記事を読んだりはしていたものの、Vagrant ぐらいしかまともに使ったことがありませんでした。 そんな私にとっては Vagrant も含めて各製品の情報をまとめて得られるという、とてもありがたいセミナーでした。 講師は @zembutsu さんでした。 発表資料は下のスライドです: HashiCode 01 - HashiCorp道と自動化ツール群 from Masahito Zembutsu 以下、講演内容のメモになります。 Tao of HashiCorp (HasihCorp道) ※今日
CHEF Business Meetup に行ってきた #getchef #getchef_ja - weblog of key_amb
5/20 クリエーションライン社で行われた「CHEF Business Meetup ~CHEF社Dicretor来日イベント~」に行ってきました。 内容は前半が ChefConf 2015(3/31-4/2開催)のレポート、後半が Chef Evangelist の Seth Thomas によるセッションでした。 以下、聴講のメモです。 ChefConf 2015 レポート クリエーションライン社顧問 鈴木さん 15分ぐらい遅刻して、前半部分を聞き損ねました。 こちらの資料は後ほど CL Lab に公開されるとのことでした。 Disney の事例 IT投資してる OSS 組合せて独自にシステム構築 独自 Cookbook 多数 独自 Supermarket 300 台の Hadoop 30 個の Cookbook 20 PB の Hadoop ストレージ BI Chef, Docker
peco をセットアップしてみた(Zsh編) - weblog of key_amb
これもだいぶ今更感ありますが、Mac の zsh に peco を入れて設定してみました。 peco について知らない人のために一応かんたんに説明すると、@lestrrat さんが元は Python の percol というツールだったものを Go 言語に移植したもの*1で、テキストをフィルタして、history などの検索を楽にしてくれるものです。 ネット上で話題になって、一部の技術者界隈で流行ったのはたぶん半年以上前で、そのときにも一瞬だけ触ったのだけど、そのときは使い込まずに終わりました。 …で、なくてもなんとかなるかなと思っていたのですが、最近「pecoないと死ぬ」と言っている人が周囲に3人ぐらいいたので、「そんなに便利なのか」と、そろそろもう1回トライしておくことにしました。 今では Qiita などに先人たちの .zshrc や .bashrc の設定がアップされているので、あ
Hugo で "bootie-docs" というドキュメンテーション用のテーマを作った #Hugo - weblog of key_amb
※2016/4/6 記事更新 こちらです。 Complete List | Hugo Themes にも Pull Request を送って、入れてもらっています。 Motivation 以前に Markdown によるドキュメント管理について、記事を書きました。 Markdown による中規模ドキュメンテーションシステムについて調べた。 - weblog of key_amb その後、Pelican や MkDocs を試したものの、なんだか帯に短しタスキに長しな感じで、必要十分なドキュメンテーション用の機能を満たすものがない感じでした。 Pelican 触ってみたところ、やはりデフォルトはブログ用ですね。ドキュメンテーションに適したレイアウトにするには Hugo などと同様、初期工数が要りそう。— きいあむ → @progrhyme (@key_amb) 2015年4月4日 だったら
MyNA(日本MySQLユーザ会) 2015年4月 に行ってきた #mysql_jp - weblog of key_amb
最近ブログが勉強会参加レポートばかりになっている感がありますが、今日(4/22)は MyNA (日本MySQLユーザ会) に行ってきました。 ここのところ話題になっていた '🍣' = '🍺' 問題や、パフォーマンス・チューニング Tips, MySQL 5.7 の性能 / 新機能と、盛り沢山の話が聞けて、大変勉強になりました。 当日の Tweet が togetter にまとめられています。 発表内容と照らし合わせて見ると、参考になる情報もあるかもしれません。 以下、発表内容のノートになります。 資料はまだネット上に上がっていないものもあるようですが、捕捉したらこちらの記事も更新します。 (愚直にメモを取っていたので、かなりの分量になりました ^^; ) 🍣=🍺 とみたまさひろさん = from Masahiro Tomita 自己紹介 日本MySQLユーザ会代表 MySQL的
CoreOS Meetup Tokyo #1 に行ってきた #coreosjp - weblog of key_amb
4/9(木) に開催された CoreOS Meetup Tokyo #1 に行ってきました。 3時間の中でイントロ除いて発表が7つあり、かなり内容が濃かったです。 一番面白かったのは @kawamuray さんの Docker に CRIU を実装した発表でした。 CRIU はコンテナ界隈でも注目度が高い技術のようで、近い将来、この時デモで見たような機能が誰でも使えるようになるかと思うととても楽しみです。 また、Wantedly や pixiv で実際にプロダクション環境で運用している話も聞けたのは収穫でした。 コンテナ技術は運用ノウハウがまだ業界的に溜まっておらず、各社手探りでやっている印象を受けました。 一方で、@higebu さんの次のコメントが特に印象に残りました。 バグは何にでも存在するからバグを恐れてたら何もできないんだよな #coreosjp— Yuya Kusakabe (
AWS ElastiCache Redis のイケてないところ ※2014/12/21 時点 - weblog of key_amb
CONFIG GET ができないとかいう制約があるのは別として、最近ハマって、他の人もハマりかねないだろうと思うことを書いておきます。 Cache Cluster のスペックアップができない RDS のように作成した Cache Cluster のインスタンスタイプを変更することはできません。 AWSサポートに問い合わせても現時点ではできないという回答でした。 また、異なるインスタンスタイプのノードをレプリケーショングループに追加することもできないため、現時点でスペックアップしたい場合、新たな Cache Cluster を作成して手動でデータ移行と、アプリケーション側のエンドポイント切り替えを行う必要があります。 最近 Multi-AZ なクラスタ構成がサポートされたので、近い将来にはスペックアップ(インスタンスタイプ変更)もサポートされると期待したいものです。 Freeable Mem
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
