Hatena::ブログ(Diary)

(ひ)メモ このページをアンテナに追加 RSSフィード

2014-07-17 (Thu)

daemontoolsなserviceをハンドリングするための Chef::Provider::Service::Daemontools を書いてみました

Chefでdaemontools配下のサービスをハンドリングするときは、コミュニティクックブックの daemontools を使ってる人が多いと思います。

こんな感じで。

daemontools_service "tinydns-internal" do
  directory "/etc/djbdns/tinydns-internal"
  template false
  action [:enable,:start]
end

notification も送れます。

template '...' do
  ...
  notifies :restart, 'daemontools_service[tinydns-internal]'
end

自分もこれを使おうと思ったのですが、いくつか不満点がありました

  • serviceとdaemontools_serviceの両対応のレシピを書く場合、
    • service と daemontools_service とでほぼ同じ記述をしないといけない
    • notifies を送る側でも service か daemontools_service か意識しないといけない
  • action :stop で svc -p (SIGSTOP) している
    • なんで svc -d (SIGTERM) じゃないんでしょうか。。。
  • サービスのハンドリングだけしたいので、daemontools のインストールとかは別に要らない
    • 依存で ucspi-tcp もインストールされるが使ってないので要らない
    • RedHat系だと "daemontools" という名前のパッケージを入れようとするが、(内部のyum reposにある)"daemontools-toaster" を入れたい
      • attribute によるパッケージ名の変更はできない
  • run ファイルの生成機能は別に要らない(あっても使わなければいいだけだけど)

ので、service リソース (http://docs.opscode.com/resource_service.html) の provider として指定可能な Chef::Provider::Service::Daemontools を書いてみました。

gem install chef-provider-service-daemontools でインストールして、こんな感じで使えます。

require 'chef/provider/service/daemontools'

template '...' do
  ...
  notifies :restart, 'service[oreno-daemon]'
end

service 'oreno-daemon' do
  provider Chef::Provider::Service::Daemontools
  service_dir '/service'
  directory '/usr/oreno/daemon/oreno-daemon'
  supports :restart => true, :reload => true
  action [:enable, :start]
end
  • provider: 「provider Chef::Provider::Service::Daemontools」は必須です
  • service_dir: svscanが監視しているディレクトリです。この下にsymlinkが作られます。デフォルトは /service です
  • directory: symlinkが指すrunファイル等があるディレクトリです。デフォルトは /usr/oreno/daemon/#{service_name} です

notifies でも既存の service と同じように 「service[oreno-daemon]」 と指定できるのがミソです。

Special thanks!

daemontools.rb を書くにあたり、ルビーカの低い自分を @ さんと @ さんに助けていただきました! あざっっっっっっっっっっっっっす!!!

2014-07-14 (Mon)

github:eで管理しているChefのクックブックを、Berkshelf APIサーバーを立てていい感じに依存解決する方法

ちょっと前にリリースされた Berkshelf 3から、Berkshelf APIというインデックスサーバーからクックブックの情報を得るようになりました。

Berkshelf APIを使うと、外部に公開していないクックブックをBerksfileで指定する際の記述が簡潔になります。

まだ日が浅いせいか、Berkshelf API + github:e の情報が少ないので、備忘録も兼ねて残しておきます。

環境は以下のとおりです。

  • berkshelf (3.1.3)
  • berkshelf-api (2.0.0)

Berkshelf APIが必要な理由

Berksfile で cookbook キーワードに git: を添えることで、github:e からクックブックを持ってくることができます。

source 'https://api.berkshelf.com'

cookbook 'oreno-apache', git: 'git@github.oreno:cookbooks/oreno-apache.git'

さて、クックブック oreno-apache が oreno-iptables に依存している(oreno-apache/metadata.rbで depends 'oreno-iptables' している)とします。

この状態で berks を実行すると、oreno-iptables が見つけられなくてエラーになります。

$ berks vendor ./cookbooks
Resolving cookbook dependencies...
Fetching 'oreno-apache' from git@github.oreno:cookbooks/oreno-apache.git (at master)
Fetching cookbook index from https://api.berkshelf.com...
Unable to satisfy constraints on package oreno-iptables, which does not exist, due to solution constraint (oreno-apache = 0.1.0). Solution constraints that may result in a constraint on oreno-iptables: [(oreno-apache = 0.1.0) -> (oreno-iptables >= 0.0.0)]
Missing artifacts: oreno-iptables
Demand that cannot be met: (oreno-apache = 0.1.0)
Unable to find a solution for demands: oreno-apache (0.1.0)

原因は、内部の github:e にしかない oreno-iptables の情報をBerkshelf API (https://api.berkshelf.com) から得たインデックス情報から探そうとして、当然そこには情報がないためです。

なので、以下のようにBerksfileに oreno-iptables の情報を書けば、うまくいきます。

source 'https://api.berkshelf.com'

cookbook 'oreno-apache', git: 'git@github.oreno:cookbooks/oreno-apache.git'
cookbook 'oreno-iptables, git: 'git@github.oreno:cookbooks/oreno-iptables.git'

しかしこれでは使いたいクックブックが依存しているクックブックまでいちいち意識してトップレベルのBerksfileに書かないといけません。ひとつやふたつならまだいいですが、増えてくると面倒このうえないでしょう。

そこで内部のクックブックの情報を返すBerkshelf APIを立てることで、このようなBerksfileを書けばよいようになります。

source 'http://berks-api.oreno:26200'
source 'https://api.berkshelf.com'

cookbook 'oreno-apache'

簡潔ですよね?

最初のsourceを参照してクックブックが見つからなかった場合は、次のsourceを参照するので、これで内部クックブックとコミュニティクックブックの両方の情報を取得できるようになるわけです。

github:e の構成

Berkshelf APIサーバーから参照する場合、github:e 上のクックブックの管理は以下のような構成になっている必要があります。

  • organizationの下にクックブックのレポジトリを置く
    • ユーザーの下ではダメです (少なくとも berkshelf-api 2.0の実装では)
    • クックブック以外のレポジトリがあっても無視されますが、クックブック専用のorganizationを用意した方がいいでしょう
  • metadata.rbのversionをgit tagする
    • 「version '1.2.3'」なら「v1.2.3」というタグをつける必要があります
    • タグがついていないとクックブックと認識されなくてハマります

metadata.rb の書き方

Berkshelf APIサーバーは、github:e から当該クックブックの metadata.rb の「内容」を得て、それをもって instance_eval で評価します。

したがって、metadata.rb に外部ファイルを参照するようなコードを書いていると、例外が発生してスキップされクックブックとみなされなくなってしまいます。

例えば knife cookbook create で作ったクックブックの metadata.rb には、

long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))

と書かれているので修正する必要がります。(berks cookbookで作ったものは大丈夫です)

自分は ../recipes/*.rb を開いて「include_recipe」しているクックブックを全部 depends するRubyコードを書いていたのでハマりました。

Berkshelf APIサーバーを上げる

berkshelf-api のインストール方法は https://github.com/berkshelf/berkshelf-api を参照してください。

github:e にあるクックブックの情報を返すために、次のような設定ファイルを作って、

{
  "endpoints": [
    {
      "type": "github",
      "options": {
        "organization": "cookbooks",
        "access_token": "YOUR_ACCESS_TOKEN",
        "api_endpoint": "https://github.oreno/api/v3",
        "web_endpoint": "https://github.oreno",
        "ssl_verify": true
      }
    }
  ]
}

起動します。

berks-api -c /path/to/config.json

うまくいけば、26200番ポートの /universe にアクセスすればクックブックの情報が返ってきます。

$ curl http://127.0.0.1:26200/universe | jq .
{
  "oreno-apache": {
    "0.1.2": {
      "location_path": "https://github.oreno/cookbooks/oreno-apache",
      "location_type": "github",
      "dependencies": {
        "oreno-iptables": ">= 0.0.0"
      },
...

berks-api はかなり短い周期で github:e にアクセスしているようで、push された情報はほぼすぐに反映されるようです。

berks の設定をする

これで適切な URL からクックブックをダウンロードできる情報は揃ったのですが、github:e から実際にダウンロードするには berks の設定が必要です。

~/.berkshelf/config.json に次のように書きます。

{
  "github": [
    {
      "access_token": "YOUR_ACCESS_TOKEN",
      "api_endpoint": "https://github.oreno/api/v3",
      "web_endpoint": "https://github.oreno",
      "ssl_verify": true
    }
  ]
}

これで berks vendor で自家製とコミュニティの両方のクックブックが取得できるようになったはずです!

2014-06-12 (Thu)

bashでもpercolをイイ感じに使う方法

@(mooz)さん作のpercolはシェルとは独立しているのですが、ググるzshと共に使っている人が多いようです。これはzshの強力な行編集機能を提供するzleに因るところが大きいためだと思います。

bashでもpercolを使っている人もいるのですが、

「絞り込んだパスへのcdを実行する」ことはできても、「絞り込んだパスを現在のコマンドライン行に挿入する」ことは実現できていない、つまりコマンド実行はできるけど行編集はできていないようでした。

そこで今回ちょっと調べてみたところ、bashでも(zleには及ばないにしても)変数READLINE_LINEとREADLINE_POINTで行編集できることがわかったので紹介します。ただし、bash 4以上が必要です。

READLINE_LINEとREADLINE_POINT

READLINE_LINEには現在のコマンド行の内容が、READLINE_POINTにはカーソルの位置が格納されます。

例えば、

_readline_test() {
  {
    echo "LINE=$READLINE_LINE"
    echo "POINT=$READLINE_POINT"
  } >&2
}

bind -x '"\C-xx":_readline_test'

とし、対話シェル上で C-x x を打つとこのような結果になります。「■」の位置がカーソルの位置を示します。

$ ■
LINE=
POINT=0

$ foo bar baz■
LINE=foo bar baz
POINT=11

$ foo bar■baz
LINE=foo bar baz
POINT=7

percol --query に $READLINE_LINE 全体もしくは $READLINE_POINT までの部分文字列を渡せば、検索文字列が入った状態で percol を呼ぶことができそうです。


またこの READLINE_LINE と READLINE_POINT は変更することもできます。変更した場合、対話シェル上のコマンドライン行をその内容とカーソルの位置に変更できます。

例えば、

_readline_test() {
  READLINE_LINE="$READLINE_LINE hok"
  READLINE_POINT=${#READLINE_LINE}
}

bind -x '"\C-xx":_readline_test'

とした場合、C-x x を押す度に「 hok」が追加されカーソルが行末に移動するはずです。


続いては実例です。

コマンドヒストリー

C-r を percol を使うものに置き換えています。念の為、C-r だった reverse-search-history を C-x r に当てています。

ヒストリーはpercolの結果で完全に置き換えて欲しいので、READLINE_LINEにはそのまま絞り込み結果を代入し、READLINE_POINTにはその長さを代入しています。

_replace_by_history() {
  local l=$(HISTTIMEFORMAT= history | tac | sed -e 's/^\s*[0-9]\+\s\+//' | percol --query "$READLINE_LINE")
  READLINE_LINE="$l"
  READLINE_POINT=${#l}
}
bind -x '"\C-r": _replace_by_history'
bind    '"\C-xr": reverse-search-history'

gitのディレクトリ{ にcd | を挿入 }

自分は git clone したディレクトリは ~/repos の直下もしくは1階層サブディレクトリを掘った下に置いているので、percolでそれを絞り込むシェル関数はこのようになります。

_select_gitdir() {
  find ~/repos -maxdepth 3 -type d -a -name '.git' | \
    sed -e 's@/.git@/@' | \
    percol
}

そこへ移動したい場合は、単純にcdすればよいです。

_cd_gitdir() {
  cd "$(_select_gitdir)"
}
bind '"\C-xg": "_cd_gitdir\n"'

次に、コマンドライン行の現在のカーソル位置に、絞り込んだ git ディレクトリのパスを挿入する場合はこのようになります。

現在の行の内容のカーソル位置のところに絞り込んだ結果を挟んで、カーソル位置を挟んだ末尾に移動しています。

_insert_gitdir() {
  local l=$(_select_gitdir)
  READLINE_LINE="${READLINE_LINE:0:$READLINE_POINT}${l}${READLINE_LINE:$READLINE_POINT}"
  READLINE_POINT=$(($READLINE_POINT + ${#l}))
}
bind -x '"\C-x\C-g": _insert_gitdir'

最近移動したディレクトリの履歴

自分は昔から Bash の小枝集 で紹介されている cdhist.sh を使っています。これを使っていると配列変数 CDHIST_CDQ に最近移動したディレクトリが記録されているので、percolから利用してみます。

_cd_cdhist() {
  cd "$(for i in "${CDHIST_CDQ[@]}"; do echo $i; done | percol)"
}
bind '"\C-xj": "_cd_cdhist\n"'

screenのアクティブwindowを選択する

screen 4.1以上なら -Q windows でリストが取れるようなのでそれでできそうです。

が、諸般の事情で tmux に乗り換え中です><

tmux の例は https://github.com/mooz/percol#tmux をどうぞ!

peco

goで書かれた peco というのもあるようです。

バイナリだけコピーすれば使えるので、いろんな環境で使いたい場合はいいかもしれませんね!

2003 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 05 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 12 |
2012 | 01 | 02 | 03 | 06 | 08 | 10 | 11 | 12 |
2013 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |