満ちずして溢れ出した Boxen のお話 (Winter ver.) - 壱

i <3 Mac
i <3 Mac / sunshinecity

んがっ。
前回のエントリーからこんなに時間経ってたん...てぇーか 2013 年、終わるじゃん orz

以前書いた "ちょろっと boxen"
あれから、まぁそれなりに「こんなもんで」な着地点を見つけたので boxen の作業については思ったより早く片付いたのですが、その処理に掛かる時間たるや...
これはさすがにイカン、と言う事で、script/boxen 走らせる前にも、も一枚、本当に必要最低限な環境をつくる為の shellscript を挟ませることに。
こちらの作業に関しての話は後として。

まぁ、何だ。
よくもまぁ、後から後かへと、華麗にも問題にぶち当たるものだと、あまりにデキナイ自分に嫌悪の渦。

結構な労力割いて、何の根拠もない期待を勝手に抱いて意気揚々と enter キーを叩くも、結果、このていたらく。
これはさすがに自分でも、おまえ痛いわ、思う。

ホントはすべて終わったら、スッキリと気分よく振り返りのエントリー書こうと思っていたのですが、
色々ありすぎて溢れ返ってしまっているような気がするし、更に、いつ思い描くようなスッキリな気分を迎える時が来るのかさえも心配になってきたので(笑 ここら辺りで、いったん整理しておこう、というお話です。

boxen の作業で知った幾つかの事。

基本、つまづいたトコロでの思い出で、 ここで書いておこうと思っているもの。 今思い起こしてみると、自分でも「え? 何でこんなところで?」と言うのばかりで恥ずかしいのが殆どだったりするのですが、敢えて。

  • Puppet でシンボリックリンクを作れる。
  • Puppet での変数のお作法、$..."${...}" 表記スタイルと使い分け。
  • Boxen がデフォルトで提供(定義)するモジュールのバージョンを別のものにする。
  • Boxen の puppet あるけど Package リソースタイプ使ってインストール。
  • Package リソースタイプ使ってのインストール、"No such file or directory" ?
  • Package リソースタイプ使ってのインストール、それの providerappdmgRsync は 3 を使いたくてやったこと。
  • Ricty も Boxen の中で全部やってしまいたくてやったこと。

シンボリックリンクを貼れる

前回のエントリーで、「シンボリックリンクって作れんだろか」と言い放って終わったのですが、やっぱりその程度のことはキチンと用意されているようで。

結論は、こういうこと。
リソースタイプ file にて、ensure 属性に link、そして target 属性にリンク元であるオリジナルとなるファイルのパスを指定する。

こんな感じになるようです。;

file { <resource title>:
    ensure => link,
    target => '<file/to/path>',
}

以下、詳細。

キッカケは、
github に預けている dotfiles を持ってきてから、それらの symlink を ${HOME} 直下に貼る、と言う手続き boxen の処理に任せてしまいたい、と考えたこと。*1

最初のアイディアとしては、
別口で用意していた shellscript があって、 ソイツを boxen サイドで着火すれば...、と考えていたのですが、pp ファイル *2 を触っているうちに、ここで出来るっぽい臭いを。

移動中の空き時間、ネット上の puppet に関するページをぼんやり斜め読みしていたら、やはりありました。

シンボリックリンク

シンボリックリンクは以下のように宣言できますが、 (略) file { '/var/log/syslog': ensure => link, target => '/var/log/messages', }

ということで、ensure => link とかで他の方々の boxen の puppet 見てみたら、ありますね。

puppet のリファレンスではコチラ
タイプ file の中で、ensure 属性に symlink 元のファイルパスを指定するだけでも良いらしいけど、そじゃなくて ensure 属性には link という値を指定し、target 属性に元ファイルのパスを指定することをオススメします、って...先の引用と同じこと書いてますね。

puppet における変数

こちらも、いたって基本的な話なのですが*3...

んなエラー。;

/opt/boxen/repo% script/boxen --no-fde
Error: Could not match ${dotfiles}: at /opt/boxen/repo/modules/people/manifests/woowee.pp:83 on node {MYNODENAME}.local
Wrapped exception:
Could not match ${dotfiles}:
Error: Could not match ${dotfiles}: at /opt/boxen/repo/modules/people/manifests/woowee.pp:83 on node {MYNODENAME}.local

問題は、変数表記に関するお作法の問題。
自分で変数 dotfiles を定義して使っているのですが、この謳い方がイケナイ、と言うのがオチ。

puppet での変数のお作法。今回のポイントは、;

  • 変数は 2 つの表記がある。$<name>${<name>}
  • {} による表記は、ダブルクォーテーションの中で使う。"${<name>}"

以下、詳細。

shellscript の癖のイキヲイで、ついこんな書き方をしてしまっていた。

# git clone 'dotfiles'
repository { ${dotfiles}:    #<- ココ(l.83)
    source  => "oreore/dots",
}
:

どうやら素直に $... 表記が良さそう、と言う事で、$dotfiles とする。

ここで、悶々とする。

色んな人たちのコードをパクリ参考にしながらやってきていて、それらを並べながら、
同じソースの中で、変数を ${...} 表記で書いても問題ないのもある。当然 $...${...} の表記が混在しているソースもあるし、勿論それらは問題なく動作するわけで、何時もの通り、この手の現実を目の当たりにすると、「その摘み分け、使い分けって?」ってなるし、さらには「どうしてここでは上手く行かないの?」と。

今思うと恥ずかしい限りなのですが prz

こういうことらしい。
変数名を "" と表記すると... ;

  • 変数は 2 つの表記がある。$<name>${<name>}
  • ${<name>} による表記方法を採る場合は、ダブルクオートで囲む*4。つまりこう "${<name>}"
  • "${<name>}" な表記を使う意味は、変数をダブルクオート内の他の文字列と区別できるようにするため*5
    インパクト優先で、強引に極端な例を作ると。;
    • ひとつは、"You need the $items."
    • もうひとつは、"You need the ${item}s"
    • 後者の方が、item が変数であることが、ぱっと見、伝わり易い。

ついでにダブルクオートの中での変数と言うのは、他の幾つかの言語同様 "interpolation" と言う事で、"補間" でいいのかしら?、変数の中身を展開してくれる。
{} 括弧で囲む表記法を、"${<name>}" と記載せず ${<name>} と裸で使うと、"${}" という文字列自身が使われちゃうよ、ということなのですね。

と言う事で、両表記スタイル選択の摘み分けは、
明らかに「あぁ、変数ね」と分かるのだったら ${...} で良くて、
何か、隣り合う文字列と紛らわしくなりそうだな、と感じるのなら ${...} を採る、となるのでしょう。

うーん...何か疲れてきた... し、一つのエントリーには、長くなりすぎるような気が。

と言う事で、今日のとこはおしまい。

*1:でも結局思うとこあって、この作業 boxen でする事は止めたのですが...

*2:our-boxen/modules/people/manifests/puppet/${github_username}.pp

*3:そんな基礎も出来てない奴が書いてんじゃねぇよ、って。...なりますよねぇ、やっぱ

*4:シンプルにしておきたかったので、かなり乱暴に表現しています。

*5:一応、ダブルクオートで囲んだ中で変数名を記述する場合には、大括弧 "{}" で囲むことを、必須ではないけど推奨とのこと。