はてなブックマーク

head と tail を使うとき、行数指定方法について。動作確認は GNU coreutils 8.19 で行っている。 head と tail のは-n 数字(あるいは--line 数字)で出力する行数を指定できる。 # 先頭3行を表示 $ seq 10 | head -n 3 1 2 3 # 末尾3行を表示 $ seq 10 | tail -n 3 8 9 10 オプションで与える数字には、プラスがつく場合、マイナスがつく場合、何もつかない場合が考えられるが、記号がついた場合に通常異なる挙動をとる場合が出てくる。 head -n -数字の場合は、「末尾から指定した行数を除いたもの」となる: $ seq 10 | head -n -3 1 2 3 4 5 6 7 tail -n +数字 の場合は、「先頭から数えて指定した行以降のもの」となる: $ seq 10 | tail -n +3

Web アプリケーションのパフォーマンスコンテスト ISUCON 3 に参加し、2 位の成績となった。どのような状態で当日を迎え、どのような作業を行ったのかをまとめる。 私自身はこれで三度目の ISUCON 参加となるが、今回チームを組むメンバーはみんな初めての参加ということもあり、事前の打ち合わせでは以下のようなことを話していた: これまでの大会の説明と典型的なアプローチ 同時に、過去にとられた戦法は参考程度であること、あくまで現物のアプリケーションを元に戦略を立てるべきでアプリケーションやミドルウェアを事前に決めることは危険であるということは強調 よく使われるミドルウェアの概要、メリット/デメリット 主要機能のほか、キャッシュ部分の永続性の有無（単純に考えればメモリだけで処理してファイルに書き出さない方が早いが、ベンチマークをまたいでキャッシュを引き継げれば切り札になり得る）、キャッシ

chocolatey の仕組みに興味を持ったので、パッケージを作ってみる。 目標は「Haskell Platform for Windows からインストーラをダウンロードしてきてサイレントインストール」ができるパッケージを作って、chocolatey のリポジトリにパッケージを登録してみる。 作業 パッケージ作成 ドキュメントでは warmup (プロジェクトのひな形を作ったり、そこで生成されたファイル内の文字列を置換したりするプログラム) を使ったやり方が説明されているけど、うまく動かなかったのでガリガリ手作業でやっていく。 前提として、chocolatey のインストール方法は済んでいるものとする。 まずはテンプレートを手に入れる。github から直接ファイルをダウンロードでもいいけど、今回の手順では clone してみよう。 # git 入れてなければ インストール cinst

プログレスバーを簡単に表示できる pv について説明する。 インストール方法 自分の環境(debian 6.0.3)だと aptでインストール出来る。RHEL系ならここかな。 使い方 端的に言うと、「cat ＋ 標準エラー出力にプログレスバー」という動きを取る。 f440@abhoth[10]:~$ yes | pv >/dev/null 529MB 0:00:08 [67.2MB/s] [ <=> ] 8秒で合計529MB、秒間67.2MBくらいで「y」の文字が pv を通り抜けてるのがわかる。 -lオプションをつけると行モードになり、転送量ではなく転送行数を調べられる。 f440@abhoth[10]:~$ yes | pv -l >/dev/null 435k 0:00:10 [45.9k/s] [ <=> ] 10秒で435行、秒間45900行くらいが通り抜けてるのがわかる。 他に

このサイトは今まで Octopress を使って生成していたんだけど、Middleman に変えてみた。 元々 Octopress の設定ファイルの書き方とかがモヤモヤするものがあって(Rakefile に設定項目埋め込んであるところとか) Jekyll にしようかなと思ったんだけど、なんとなく Middleman にしてみた。その後の感想など。 (もう2ヶ月くらい前の話なので、移行当時の記憶はおぼろげ) ビルド時間が短くなった 素の jekyll はビルド早いんだけど、Octopress は結構遅いんで気になっていた。middleman は Octopress よりかは早い ブログの内容はほぼそのまま使い回せた メタデータ部分を s/categories/tags/ で置換したくらいだったと思う 公開されているテンプレートが少ない 自分でちまちま書いてる middleman-livere

ちょっと前にsupervisorを使ったのでやり方をまとめておく。 公式サイト: supervisor supervisorはプログラムの起動、停止を管理するツール。daemontools がわかるなら、あんな感じのソフトだと思ってもらえれば早い。daemontoolsよりも標準的なディレクトリ構成で使えるぶん、導入障壁は低いと思う。 最近のLinuxなら、パッケージですぐインストール出来る。以降の説明は debian (6.0.3)、superviser 3 系によるもの。 インストール $ sudo apt-get install superviser 確認 $ sudo service supervisor status # 起動確認（名前表示されない……） is running $ sudo service supervisor stop # 停止 Stopping supervi

ここ最近話題に上がることが多い Immutable Infrastracture と、その他仮想環境周りについての雑感。 Immutable Server や Immutable Infrastracture っていう単語がいろんなところで目に入るようになった。とくに Chad Fowler がブログで取り上げたり、Food Fight に出たり して、世間でも関心が高まった感じがある。 プログラムを書く人にはご存じの通り、この Immutable っていうのは状態が変更出来ないことを指している。Immutable な Infrastracture っていうのは、ざっくり言うと「運用中のサーバーに変更を加えない」っていうアプローチでサーバーを管理しているスタイルのこと。 (ファイルシステムを読み取り専用にする、とかそういう話じゃなくて、あくまでそういう方針でやろうっていう話) サーバーの設

/etc/yum.confでkeepcache=1にしておくと、インストールしたパッケージがキャッシュされるようになる。これが無効化された状態だと、パッケージアップグレード時に問題が起きても元に戻せなくなるので有効化しておいた方がいい。 あるパッケージについて、どのバージョンが利用可能な状態かは以下で確認できる。 $ sudo yum --showduplicates list パッケージ名 RHEL なら過去のバージョンまですべて手に入るけど、CentOS だとOSリリース時のバージョンと最新版しか手に入らない模様。リポジトリ上なりキャッシュなりで過去のバージョンが手に入るのであれば、yum install や yum update は以下の手順でロールバックが行える。 # yum の利用履歴を確認 $ sudo yum history # 履歴から詳細を確認 # 未引数なら直近、引数あ

Mesos をインストールするとき各マシンでビルドはしんどいので、fpm で Mesos の RPM を作ってインストールしている。ビルドからパッケージ作成までの作業ログを残しておく。 fpm は Ruby の gem や Node.js の npm などのプログラミング言語のライブラリ、あるいは直接ディレクトリから RPM やら Deb やらのパッケージを作成するソフトウェア。 Mesos はクラスタ構成のリソースをよしなに管理するソフトウェア。 今回の話では具体的な使い方までは触れない 手順 作業環境は CentOS 6.4 x86_64。 Ruby をインストール。 sudo yum install ruby.x86_64 rubygems ruby-devel.x86_64 rpm-build.x86_64 fpm をインストール。 sudo gem install fpm --n

sub は 37signals が公開しているスクリプト群。サブコマンド付きのコマンドを作りたいとき、補完やヘルプメッセージなどの便利な機能を提供してくれる。 使い方 以下の簡単なコマンドを作って、動作を確認してみることにする。 ex. browse safari http://google.com/ コマンド browse にサブコマンドでブラウザ(safari, chrome, opera, ...)を与え、 最後の引数で渡された URL が開く。URL が渡されなければ、ブラウザの起動のみ行う。 なお、確認はすべて Mac OS X 10.8 上 の zsh で行っている。 初期化 $ git clone git://github.com/37signals/sub.git browse $ cd browse $ ./prepare.sh browse # 以下のメッセージが表示さ

ちょっと前から Docker を使っているので、その話。 Dockr について Docker は dotcloud がオープンソースで公開している、コンテナ技術による仮想化ソフトウェア。 以下のテクノロジーベースにしている: LXC 前にも書いた。Xen とか VirtualBOX みたいにホスト内に仮想マシンを立ち上げるんじゃなくて、ホスト内の隔離された環境で仮想マシンを動かす技術。物理マシンをシミュレーションしているんじゃないってことは、VPS とか EC2 とかの仮想マシン上でも問題なく動くし、マシンを起動するプロセスが不要となるので、一瞬で使い始められるというメリットにつながっている。 AUFS UnionFS(ディレクトリを重ね合わせることができる)の実装の一つ。元の仮想マシンイメージを書き換えないで、更新が発生した部分は別の場所に書き込んでいくようになっている。これにより、仮想

rundeck でjenkins上の成果物をデプロイしよう、という話。 rundeck について 公式サイト ITオペレーションのコンサルやってるDTO Solution（Depops関連の資料とかでよく会社名は見かけますね）が作っているデプロイ用のツール。元々はControlTierっていう管理ツールがあって、そこから分家した。ControlTierはサーバー/クライアントモデルだけど、サーバー側しか用意しなくていいRundeckのほうがお手軽度高い。 複数のサーバーを対象に状態を変更するのが目的で、capistranoとかfabricとかと同じジャンル。GUIで操作するのが特徴なので、webistrano とかに近い。 GUI（笑）みたいに思うかもしれないけど、画面上から履歴が確認できたり、ブラウザがあればどこからでもデプロイ出来るのって、運用の敷居下げるのに貢献してくれると思う。 r

Chef のインストールは結構面倒くさかったんだけど、オムニバスインストーラーが出たことで状況はがらっと変わって、簡単に導入できるようになった。このオムニバスインストーラーの仕組みは汎用的に作られているので、他のツールでも適用できるという話。 オムニバスインストーラーについて Chef のオムニバスインストーラーを実行すると以下のようなディレクトリ構成でファイルが置かれる: /opt/chef/bin/ ... Chef 関連のスクリプト /opt/chef/embedded/ ... ruby インタプリタ、Chef とその他依存パッケージ (/usr/bin/ ... /opt/chef/bin/ 以下のものがシンボリックリンクが配置される) 以上の通り、/opt/chef の中に動作に必要なものがごっそり置かれる。アプリケーションレベルでプログラミングの処理系を持っちゃうというのはこ

ISUCON 62016.10.29 DLiteでOS X上にDockerの環境を構築する2016.02.22 ISUCON 3 の参加記録2013.11.11 Immutable Infrastracture について2013.08.10 ブログエンジンを Octopress から Middleman に変えた2013.08.10 仮想環境構築に docker を使う2013.06.17 yum のパッケージキャッシュについて2013.06.15 omnibus を使って オムニバスインストーラーを作成する2013.05.06 fpm で Mesos の RPM を作るまで2013.05.03 構成管理ツール Ansible について2013.04.06 イベント管理にSplunk Stormを使ってみる2013.03.17 FluentdのデータをGraphiteに出力するときのTip

Ansible というサーバーの設定を管理するツールの説明。いわゆる構成管理 (CM: Configuration Management) にカテゴライズされるもので、Puppet や Chef の親戚みたいなものと考えてもらえればだいたいあってる。 概要 リード開発者は Michael DeHaan で、現職の AnsibleWorks の前は Redhat で Cobbler や Func に携わっていたり、Puppet labs でプロダクトマネージャーしたりしているという経歴の持ち主。 Ansible は Python で書かれている。同じジャンルで Python 製というと Salt が有名。Chef の場合、レシピを書くためには Ruby の知識が必要となってくるけど、Ansible はどんな言語でもモジュールが書けるようになっているので、運用にあたって Python の知識は

ubuntuにはPPAという仕組みがあり、プロジェクトホスティングサービスlaunchpad と連携してパッケージを簡単に配布する仕組みが用意されている。今回は、githubを使ってリポジトリにpushしたら自動的にRPMパッケージを公開する方法をまとめる。 ※ PPAだとサーバサイドで各種プラットフォームにビルドしてくれるが、そこまではサポートしない。あくまで配布だけ。RPMをどうやって作るのかについても触れない。 以下はhaproxy を公開するときの例。haproxyのソースにはRPMのspecファイルが含まれているので、簡単にrpmが作成出来る。 手順 git リポジトリを作成 Create a New Repository - github からリポジトリを作成。 ディレクトリ構造を作成 以下はCentOS 5 64bit 版とソースRPMを配布する場合 $ mkdir -p h

fluent-plugin-graphite 利用時のメモ。 Ops界隈での可視化というと、ここ何年かはGraphiteでグラフを作ってそれを他のツールで表示する、みたいなのが多い。Fluentdのデータを可視化したい場合はGrowthForecastが使われることが多いけど、Graphite使ってみるといろんなツールと組み合わせられておもしろい。 Fluentd から Graphite へデータを送るのは Fluent-plugin-graphite を使えば簡単に実現できそうなんだけど、プラグイン側のインターフェース(:key や :count といったキーが必要)に合わせて入力のデータを整形する必要がある。 こういった調整は、out_map を使うことで実現できる。 <source> type tail format apache path /var/log/httpd/access

Webサーバーのログでピンポンゲームの映像を生成するlogstalgia。 homebrew がインストール済みなら以下で動かせる。 gem install apache-loggen brew install logstalgia apache-loggen --rate 10 | logstalgia - apache-loggen はApacheのダミーログを生成してくれるスクリプト。便利。 参考 logstalgia apache-loggen

Fluentdで取得した情報を可視化したいとき、fluent-plugin-growthforecastを使ってGrowthForecastにグラフを作る方法がよく知られている。GrowthForecastはインストール後すぐに使い始められるお手軽ツールなんだけど、それすら面倒くさい、自前で環境を作るのが面倒、というときにはStatHatを使うと簡単に可視化を実現できるという話。 StatHatはシンプルなインターフェースで必要十分な機能があり、しかも無料で使えるというサービス。HTTPでデータを登録するだけできれいなグラフが簡単に生成できるので、幅広い用途で利用できる。 以降、FluentdとStatHatを組み合わせて利用するための設定を説明する。 作業 StathatのSign upにアクセスしてメールアドレスを登録し、折り返し届くメール内のURLからパスワードを登録すればすぐ使い始

一身上の都合で Windows 7 上に Node.js の開発環境を整えたんだけど、コマンドラインからの操作だけで開発環境がそろう時代になっていたことに驚いた。 そのときの作業メモ。 コマンドプロンプト起動: # Chocolatey のインストール @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('http://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin # システムドライブ直下にインストールするの微妙…… # 追記: [システムディスクの直下にインストールする理由](https://github.com

ネットワーク経由で大量のデータをやりとりしたいが、メインのサービスには影響を与えたくないという場合がよくある。rsyncやscp など、大きなファイルの転送を考慮されたコマンドではネットワーク帯域を制限するオプションが用意されていることも多いが、自作のツールなどに帯域制限を実装するとなるとかなり面倒くさいことになる。 Linux で帯域制限をしたい場合、tc や cgroup を使う方法がよく知られている。ただ、「あるコマンドにネットワークが占領されないように穏やかに実行したい」というニーズに対しては大げさで、またオプションが難解だったり管理権限が必要だったりといったことから二の足を踏む感じのものだった。もっと普段使いに適したツールがないものかと探していたところ、こういったシーンではTricleがかなり有効だと言うことがわかった。 インストール Debian, Ubuntu なら公式からパ

イベント処理ツール riemannを使ってみたのでその感想。 サーバーは clojure で書かれている 設定ファイルは S 式 クライアントは各言語版がある http://aphyr.github.com/riemann/clients.html サーバーの状態は riemann-dash という sinatra でできた Web 画面から確認できる クライアントからのメッセージはイベントと呼んでる host, service, state, time, description, tags, metric, ttl というパラメータを持っている サーバー、クライアント間は Protocol Buffer で通信する 公式サイトではサーバーの tar ball と deb パッケージを配布している。動かすためには、Java で実行するだけ。 $ wget [http://aphyr.com

Webアプリケーションを構築する上で、運用中に発生したファイルをローカルのファイルシステム上に保管すると、スケールを阻害するため好ましくないことが多い。 そのため、アプリケーションの設計の段階からCDNの利用したり、ファイルの管理だけ別のサービスに切り出したりすることを考慮すべきだけど、いろいろなしがらみのた めにどうしてもファイルを複数台のサーバーで共有するようなシステム形態にせざるを得ないことが往々にしてある。 サーバー間のファイル共有のための方法として、lsyncd やDRBDを使ったり、NASを介したりするなど様々な方法があるけど、[GlusterFS](http://www.gluster.or g/) がとても便利。特別な機器を必要とせず、すでにある環境に対して導入でき、信頼性とスケーラビリティのあるクラスタリングファイルシステムを手早く構築するこ とができる。 Gluster

ほんの数年前までVPSといえばLinode、Slicehostなどの海外のサーバーしか選択肢がなかった。ls を実行しても一呼吸おくほどのレイテンシーがあるような環境で、128MBくらいのメモリを何とかやりくりしてRailsを動かしていたが、現在では月1000円程度で用途によっては手に余るようなスペックが手に入るようになっている。そんなVPSの余ったリソースを使って、仮想環境をたてようというのが今回の目的だ。 LXCは、他の仮想化方式と比べてオーバーヘッドが少なくきびきび動くし、必要であればCPUやメモリの制限をつけることもできる。RPMやDebのパッケージ作成をしたり、Chefのcookbook作成などで独立した環境を手軽に構築したい人には特に有用に思う。また、簡単にネットワークが作れるので、複数台構成のソフトウェアを1台のマシンのなかで動かすことが出来る。今回は動作確認として Perc

管理対象のサーバー台数が少ない場合など、chefのサーバーを運用するコストとベネフィットを天秤にかけてみて、ああこれどう考えても労力ペイできないな、でも設定ファイルを手動で管理するのはやだな、といったときに[roundsman](https://g ithub.com/iain/roundsman)を使うといいという話。 roundsmanは、chefのレシピを転送してchef-soloを実行するcapistrano向けライブラリ。アプリケーションのリリースタイミングに併せてインフラ設定の変更が必要になることは往々にしてあるので、capistranoを使ってデプロイとインフラ設定変更を一括適 用できるのは便利だ。 ここでは、Railsアプリを対象にroundsman適用までの作業を簡単にまとめる。 手順 まずは適当なRailsプロジェクトを作るところから。 PROJECT="my_fant