rbenv についての環境変数をpathで指定したつもりだったのに、なんで command not found になってしまうのだろう。
==> default: Error: /home/vagrant/.bash_profile: line 4: rbenv: command not found
==> default: sh: rbenv: command not found
==> default:
==> default: Error: /Stage[main]/Main/Exec[install ruby]/returns: change from notrun to 0 failed: /home/vagrant/.bash_profile: line 4: rbenv: command not found
==> default: sh: rbenv: command not found
==> default:
==> default: Notice: Finished catalog run in 0.39 seconds
HOMEの環境変数が指定されていなかったことが原因だった。
- puppet の atributesである、environment と path の違い
- 環境変数とコマンドサーチパスの違いがわかっていない
- コマンドサーチパスは、環境変数$PATHに設定される
- exec は環境変数、コマンドのサーチパスが空の状態でコマンドが実行される
でもまだ rbenv が command not found になる。
command => "bash -c 'source /home/vagrant/.bash_profilei' ; env > /tmp/env ; rbenv install 2.1.5",
クオートの位置が間違っていた!
上のコードで書いていたのですが、この場合だと source
、env
、rbenv
のプロセスが違うものになってしまうのであった。
bashという親プロセスから子プロセスをはやして実行していることを忘れておりました。
command => "bash -c 'source /home/vagrant/.bash_profile ; env > /tmp/env ; rbenv install 2.1.5'",
ということで、修正してみたらrubyをインストールすることができました!
==> default: Notice: Compiled catalog for localhost in environment production in 0.40 seconds
==> default: Info: Applying configuration version '1418704433'
==> default: Notice: /Stage[main]/Main/Exec[install ruby]/returns: executed successfully
==> default: Notice: Finished catalog run in 218.26 seconds
おふ。。今度はgemのpathが通ってなさそう。
==> default: Error: Could not find command 'gem'
==> default: Error: /Stage[main]/Main/Exec[install bundler]/returns: change from notrun to 0 failed: Could not find command 'gem'
- gem の path は.bash_profile に書かれていたことを初めて知った。
- そもそもbash_profileが分かっていないみたい。
- $PATH とは "現時点で環境変数 PATH に設定されているパス名"
- bash_profile の中に$PATHも環境変数に含めるという設定がある。
- ここに今回扱うコマンドたちpathが入っているので、これを環境変数に含めているのかぁ。
$ echo $PATH
/home/vagrant/.rbenv/shims:/home/vagrant/.rbenv/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/sbin:/usr/sbin:/home/vagrant/bin
- でもこの$PATHっていつこの設定になったんだろう?(何かインストールすると自動的に$PATHに設定が書き込まれるのかな?)
テンプレートを使ったらあっさりできた。
-
それ自体に実態は無いrpmパッケージの集合体(rpmの機能)
-
実はvimもvirutal package で、vim hogehoge がいくつも組合わさったものでしかない。
-
nagiosuも、nagios mysql .. http のようなプラグインを全部入れることによってたくさんの機能が使える。 このように、依存したものを全ていれてしまう傾向が強いので、4系ではもう virtual package は true でいいよ!となり、true がデフォルトとなった。
-
今回は、自分たちが使っているのは3系のためデフォルトでfalseになっており、実行するたびに最新(4系)はtrueなんだけども、大丈夫?っていう警告文がでていたのであった。
-
virtual package がどうかの見分け方は yum list hogehoge 。ここに含まれていなければ virtual package の可能性大
-
puppet2系はデフォルトでvirtual package はなかった(実質true)。3系で、名前の衝突が怖いかな?個人のリポジトリとか扱うと怖いよね?これfalseにしようよ!ってことでfalseに。でも結局4系で virtual package はデフォルトtrue となる。
-
現在では、デフォルトはture にしておいて、名前の衝突や他に問題があるときだけfalseにする。クラスを指定したりして限定的にpuppetのデフォルト機能を使って false に指定すればおk。
virtual resource はpuppetの機能。コンパイルもされないし、ないのにあるように仮想的に何か作ってしまうみたい。 本番とは乖離すべきもの。開発環境等テストとかで使うといいっぽい。
今日でひととおりprovisioningができたました(まだvagrant up で一発で通らないので、依存関係の問題を修正する) 明日はコーディング規約に則り、コードを奇麗にしていこうと思います。その後にPRだします!
ペパボコーディング規約
- 実行ディレクトリがあやふや。ある程度あっていればいいのかな。。
- puppetはデフォルトだとpathが空になってしまうので、フルパスで書かない場合は逐一指定する必要がある
- 先頭が大文字のリソースタイプはデフォルト値になるため、そのソース内で同じリソースタイプであれば、どこでも参照されるようになる。これを使ってDRYにしていこう。
- ダブルクオートは変数展開されるから、そういった用途にのみ使うこと
- 0644だめ。444に!
- ensure はソースを扱っていればpresentはいらない