chefになろうと思う。
cookbook片手にrecipieを読み解きknifeを振るう感じで。
沙耶です。ruby大ッ嫌いなんだけど！ｗ
とりあえず、インフラ構築のプロビジョニングがお仕事になる予定なので、puppetかchefあたりをマスターしておきたい。と言うかいちいちフルスクラッチで組むとかめんどくさい。
もう歳なんでいろいろ抜け落ちるしさ。
と言うわけで、DevOpsなんて言葉に踊らされてchefを突っ込んでみることにする。
chef自体は問題ない。yum installであっさり入る。問題はそこからだ。
gemとknifeとrubyが本性現して牙をむいてきた。
とりあえず何も考えないでgem i knife-soloとかぶち込む。
ちなみに僕の中でのgemの位置づけはCPANみたいなもんだろ。くらいの認識である。
怒られる。主にgemからRubyふるいとか怒られる。
CentOSのRuby古いもんな。
コードが無けりゃあそりゃあ何もできないよな！ よしよし、おじちゃんRubyをアップデートしてあげようねぇ。
まるでいたいけな幼女を怪しく誘うおじさんのごとく、優しくRubyのアップデートをしようとする。
rpmパッケージが無い。
いやbaseのリポジトリに無いのはともかく、EPELやRemi、rpmforgeまで全滅…だと…。
めんどくせぇ。ソースから入れるとかしたくねぇし依存関係でひどい目に合いそうな予感がする。
よし、ここはrbenvだ。rbenvはRubyを切り替えながら使える便利ツールらしい。
入れ方はっと。
githubからコード取ってこい…だと…。
git入れてねぇよばーかばーか！！！
なきながらgitを入れようとすると、今度はyumさんに怒られる。
rpmforgeにgitあるけど依存関係が解消できないから入れさせてやんねぇよ！
とかなんかダイナミックなこと言ってくる。困る。
いやリポジトリん中に全員居るじゃねぇか何言ってんだお前。
うだうだいろいろ調べる。
yum install git –disableexcludes=main
まさかmainを殺すとかおもわねぇよばーかばーか。
ようやくgitが入る。使わないのに。ついでに使わないのにsubversionまで依存関係で入る。ただのWebサーバなのに。
で、ようやくrbenvのコードを取ってきて、ruby-buildのプラグインも入れる。
rbenv install ruby
でruby2.1.5入る。rbenv global 2.1.5でとりあえずどこでも2.1.5環境にしてしまう。なぜならめんどくさいから。
さあ、これでchefになれるかな？
gem i knife-solo
ゴゥ！
gem「ソースコードが見つかりません」
ばーかーなー！
もうこのあたりでほぼブチ切れしそうである。むかついたからrubygemsからコードをローカルに持ってきて強引なドリブルをしてやろう。
https://rubygems.org/
ブラウザ「そのようなサイトは存在せぬ」
バーカーなー！ Googleさんキャッシュしてんだろうがよおおおお！！！
こっからもうRubyとまったく無関係な世界での調査が始まる。
ただし原因はすべてRubyにある。
死ねばいいのに。
えーっと、rubygems.orgはAWSにホストされてるけどtokyoリージョンのcloudfrontが死んでるっぽくて国内からだとそもそもnslookupすらできないと。GoogleDNSさんは一応IP返してきたけど、cloudfrontに向かってしまうので、結局見えない。
こういうことらしい
おいこれどんだけ放置されてる問題なんだよ。あほか？
よくこれでrubyrubyとか言うな、国内の人。バッドノウハウ以外の何なんだこんなもん。
とりあえずこれでコードはもってこれるようになった。
なげぇよボケ。
gem i knife-solo
さあゴゥ！
gem「SSL証明書がおかしいんじゃねぇか？」
は？え？え？ この人何言ってんの？
しかたねぇ。
$ ruby -ropenssl -e “p OpenSSL::X509::DEFAULT_CERT_FILE”
“/etc/pki/tls/cert.pem”
$ ls -la /etc/pki/tls/cert.pem
lrwxrwxrwx 1 root root 19 10月 28 15:36 /etc/pki/tls/cert.pem -> certs/ca-bundle.crt
おい、いい加減にしろよこのクソ宝石。あんじゃねぇか。しかも更新ちゃんと最近だよボケが。ああ？ 喧嘩売ってんのか？
結論：
$ rbenv exec gem i knife-solo
ということらしい。rbenvの環境変更がgemの内部には届かないってことか。
わかるかボケが。
＃CPANくらいの気分でやっています。
成熟してない、というかなんというか…。情報も分散しまくってるし、よくもまあこんなもんみんな使おうとか思うよね。
とりあえずbudler入れてみて、正常にgem経由で入ることを確認。
まあいいや、そーれknife-solo入れろォ！
ずらずらと依存関係っぽいものが突っ込まれていく。よし、これで一安心だ。
ERROR: While executing gem … (Gem::RemoteFetcher::FetchError)
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://api.rubygems.org/gems/hashie-2.1.2.gem)
…何。何なの。ほんと喧嘩売ってんの？またなの？死ぬの？
もうね…。なんというかね…。
あれだ。何か実行すると必ずエラー起こすように作ってんだ、rubyの開発者ってやつは。エラーが置きなければならない。とか仕様書に書いてあるんだ。
だってそうじゃないとここまで意味不明にツールをインストールするのを阻害する理由なんて僕はほかに思いつかないし、こんな意味不明のエラーメッセージ出されても困る。
まああれだ、api.rubygems.orgがまたどーせtokyoリージョンが云々かんぬんだろ。IPでつないでやろう。
nslookup api.rubygems.org 8.8.8.8
GoogleDNS先生「ごめんそれ俺も知らん」
まーじーかーよー！ 要するにアレか、gemのスケルトンにかかれてるソースの取得位置がすでに更地ってことかおい。どっかのサードパーティのよそ様からとってこいとか書かれてるならともかく、rubygems.orgの中ですでにトラップか！
ちょっと面貸せコラ。
Perler先輩さんが〆るゆうてんぞコラ。LL言語の分際でドンだけ邪魔すれば気が済むんじゃ。phpのほうがまだ素直な子じゃないか。pearウザいけど、ここまで原因不明なエラーメッセージなんかださねぇわ。
CPAN先輩がちょっと校舎裏で呼んでるって伝えとけ。
言語的にどうのこうのじゃなくて、それを構成する足回りへの配慮が無さ過ぎてRubyの思想以上にその取り組み姿勢が気に入らん。
マジでいっぺん死ね。
お手上げ。ただでさえブラウザで行くことすら困難にされてるrubygems.orgの中から手探りでhashieのコード位置を探せというのか。
$ rbenv exec gem i hashie
Fetching: hashie-3.3.2.gem (100%)
Successfully installed hashie-3.3.2
Parsing documentation for hashie-3.3.2
Installing ri documentation for hashie-3.3.2
Done installing documentation for hashie after 1 seconds
1 gem installed
とりあえず単体でぶち込む。最初は怒られたが、しばらく間をおいて実行すると通過。
…なに。なんなの。なんの嫌がらせなのこれは。
rbenv exec gem i knife-solo
再度チャレンジ！（いい加減あきらめろよ、と思うかもしれませんが、DevOpsの古参puppetも結局rubyなんだよね
どうせ同じことになるんなら、ね。
Chefの概念が難しいとかなんとか言われているけど、そりゃこれプロビジョニングしたことない人にはむつかしく思えるよね。
一回でも自前でプロビさせるためのコードをPerlだのSSHだのSCPだのを取り混ぜて苦心して書いた人としては、おお、こんなにわかりやすくなってんのか！みたいなとこが多いですね。
ええ、もうね、Rubyがらみのごたごたの間にChefの本読み終わっちゃいました。
そしてこのRubyがらみのごたごたがまったくほかの構築の役に立たないという現実。そんなもんのために使わされる時間が無駄でしょうがない。
ほんと、ちょっと本気でRubyな人はそのへん考え直したほうがいいと思う。便利便利ーっていうほど便利じゃねぇよ。
ましてgemに依存してるrailsも同じような話がいっくらでも転がっていそうです。
管理される側のノードはchef入れればそれで終わりなんでRubyとかマジどうでもいいです。唯でさえそんな好きじゃなかったのに、心底嫌いになってしまった。これを覆すような何かをもってきてくれる人募集。
やっぱ僕Perl姉さんが居ればそれでいいです…。
$ rbenv exec gem i knife-solo
ERROR: While executing gem … (Gem::RemoteFetcher::FetchError)
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://au-m.rubygems.org/gems/hashie-2.1.2.gem)
…えーとごめんなさい、私あなたの言ってることが理解できないの。
hashie入れてやったやん！ ナンデ！ ナンデニンジャ！？ 3.3.2入れたからか！？ 2.1.2ピンポイントでないと動かないのか！？ キエエエエエ！
ああもう！ なんなのこの子！ もうこれはknife-soloのgemspecが問題なのか、rubygemsにこういう風潮が蔓延してんのかしらんが足回りの整備がひどすぎる。
$ rbenv exec gem i hashie-2.1.2
ERROR: Could not find a valid gem ‘hashie-2.1.2’ (>= 0) in any repository
はいはいそうでしょうねそんな風なこといわれると思ってましたよ。
マニュアルとかヘルプとか読んでも居ないしね！ -vオプションとか知るかボケ。yumさんの柔軟さ見習え。
$ rbenv exec gem i hashie -v 2.1.2
Fetching: hashie-2.1.2.gem (100%)
Successfully installed hashie-2.1.2
Parsing documentation for hashie-2.1.2
Installing ri documentation for hashie-2.1.2
Done installing documentation for hashie after 1 seconds
1 gem installed
よし入った。
gem i knife-solo、いってみよーかどー！
＃たぶん3.3.2と2.1.2で喧嘩するんだろうなとかもはやあきらめた気分を出しつつ。
$ rbenv exec gem i knife-solo
ERROR: While executing gem … (Gem::RemoteFetcher::FetchError)
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://au-m.rubygems.org/quick/Marshal.4.8/mixlib-log-1.6.0.gemspec.rz)
…しつこい。せめて全部試して失敗をリストして出せ。
まあ解消法がわかってしまえば早いな。あとは失敗するたびにそれを個別にバージョン指定で入れて、knife-soloやってはの繰り返しか。
…うっぜぇ…マジ死ね…。
その後はさくっと進んでったが、chef-11はいってんのに勝手にchef-12も入れられてた。
…ちゃんと11に上書きしてくれてんだろうか。11はrpmで入れてるんだけど…。
まあ絶対やってないよね。つことはchefのどっちが動いてるのかも意識しながらやらんとあかんのかうわめんどくさい。
とりあえず終わったー。
もうknife soloが誰を呼び出しているのか、どこから呼び出しているのか、深くは考えないことにしよう。
で、あとはサードパーティのクックブックを快適に使うためにberkshelfもあったほうがいいよ、と。
インストールは？
「gemでやるんだよ！」
おお、神よ。死ね。ほんと死ね。
$ rbenv exec gem i berkshelf
とりあえず突っ込んでみる。通ればよし。通らなければまたRubyの悪口を書けばいい。
とりあえずrubygems.orgにつながるようになってからはまあ基本的な対処なのでそこはまあいいや。
と思ってたら
Building native extensions. This could take a while…
ERROR: Error installing berkshelf:
ERROR: Failed to build gem native extension.
/home/*****/.rbenv/versions/2.1.5/bin/ruby extconf.rb
-> sh /home/*****/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/dep-selector-libgecode-1.0.2/ext/libgecode3/vendor/gecode-3.7.3/configure –prefix=/home/*****/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/dep-selector-libgecode-1.0.2/lib/dep-selector-libgecode/vendored-gecode –disable-doc-dot –disable-doc-search –disable-doc-tagfile –disable-doc-chm –disable-doc-docset –disable-qt –disable-examples –disable-flatzinc
checking for the host operating system… Linux
checking for g++… g++
checking whether the C++ compiler works… yes
checking for C++ compiler default output file name… a.out
checking for suffix of executables…
checking whether we are cross compiling… no
checking for suffix of object files… o
checking whether we are using the GNU C++ compiler… yes
checking whether g++ accepts -g… yes
checking for gcc… gcc
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking for ranlib… ranlib
checking for diff… ok
checking for tar… ok
checking for make… ok
checking for sed… ok
checking for perl… ok
checking how to run the C++ preprocessor… g++ -E
configure: error: Your version of gcc is too old. You need at least version 4.2.
extconf.rb:98:in `block in run’: Failed to build gecode library. (GecodeBuild::BuildError)
from extconf.rb:97:in `chdir’
from extconf.rb:97:in `run’
from extconf.rb:104:in `
extconf failed, exit code 1
Gem files will remain installed in /home/*****/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/dep-selector-libgecode-1.0.2 for inspection.
Results logged to /home/*****/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0-static/dep-selector-libgecode-1.0.2/gem_make.out
…なんかいきなりコンパイルおっぱじめてコケてやがる。阿呆か。
gccのバージョンが古い、だと。
$ rpm -q gcc
gcc-4.1.2-55.el5
いや確かに4.2以下だけど、いったいなんの機能がほしくて4.2なんだか…。どんだけ先進的なコード書いてるんだ。
レガシーな枯れた人たちを無視してる感がすげぇわｗ
そしてそのシステムの目的がプロビジョニングってんだから笑い話だなこれ。
まあChefが悪いわけではなくてberkshelfの依存先のコードの問題なんだろうけども。
さて、なんでChef入れようとしただけでGCCの導入までやらねばならんのか、まったくわからなくなってきた。
とりあえずyumみたらgcc44が居るからこいつ連れてくるか。
依存関係もbinutils20だけみたいだし。
alias gcc=gcc44しておいて、そーれrbenv exec gem i berkshelfでれっつごー。
configure: error: C++ compiler cannot create executables
ちっ、C++かよ。先に言え先にｗｗｗｗ
yum install gcc44-c++
ほらこれでいいだろ。
yumさんは楽でいいなぁおい。
あとはこれのコンパイルが終わればようやく設定してリポジトリが作れるわけだ。よかったよかっためでたしめでたし。
＃なんかもうあらゆることをやり仰せた感
あれ？ プロビジョニングはどこいった？
ところでその忠告ちょっと遅かった。
もう掘り終わった後だｗｗｗ
まあffiではトラブらなかったが、やはりgemが駄目すぎる。あらゆる意味で洗練されていないし、その向こうにいるユーザーが見えていない。
僕のように趣味でたたいてコケてそれをきゃっきゃうふふ言いながら喜べる人種はまだいい。RubyをDisりまくってるけど、決してだからといって否定したいわけでもないし、Rubyの言語的なセンスはある程度認めているつもりだ。
決定的に駄目なのは作り手の問題だと思っている。言語設計には罪は無い。たぶんｗ
要するに作り手側の意識が妙に先走っているのだ。そこには多様な環境と多様な人々がそのコードを使うのだ、というほんの少しの思いやりが無く、俺んとこでうごいたぜ、だからとりあえず公開。みたいな。
まあOSSなんでね、それはいいよ。
でもそれならそれで、広く使われたい、なんて望むべきじゃないんじゃないのかなぁ。この敷居が、Rubyへの渇望からきているならいい。
でもRubyを必要としていない人が、ツールの言語としてRubyが使われてしまったばっかりに同じ敷居を乗り越えなければならない理由とはどこにあるのだろう。
僕はChefが使いたかっただけだ。それがPythonでかかれていようがRubyだろうがC++だろうがなんでもいいんだ。そのツールの構造と理念を見たかっただけだ。Rubyを知りたかったわけじゃない。そして、Pythonで書かれているyumなんかでここまでひどい目に合ったことなんてない。
だってそうだろう、yumを使ってる人はPythonを知りたいわけじゃない。パッケージの管理がしたいんだ。なのにPythonのライブラリのインストール方法とかを学ばなくてはパッケージ管理をする資格はない、なんていわれているのと変わらないじゃないか、これじゃあ。
目的と手段を取り違えて入れ替えて、それを喜んでいるように見えてしまう。特にgem、お前はｗ
Vagrantはgemを取り込んでないのかー。まったくインストールにこまらなかったな、アレは。というかRubyであることすら意識しなかった。
それが正しいと思う。
だって、ゲームしたいだけなのにC++のコンパイルについて熟知しないとゲームが始まらない、っておかしいだろう？
ゲームパッケージならインストールされたらゲームができるべきだろう。
なんてつらつら書いてるわけだけど、何でかってコンパイルしています、でberkshelfが高負荷になったままくっそひどい状態になっているからだ。
どういうことだこれはｗｗｗｗｗ
いったい何をどんだけコンパイルしているんだお前は？
いつこれ終わるんだろー…。
＃結局ひどすぎたのでCtrl+Cした。シグナルは受け取る状態にあったようだけど、いくらなんでもこんなに重いコンパイルするような代物かぁ？
その後。
Ctrl+Cでとめてもリソース握ったまま離してくれません…。
シグナル受け取ったら処理してから死んでくれよ…。kill -9で殺しにいってるんじゃないんだからさぁ…。
あーあー。再起動コースですね…勘弁してくれ…。
Chefを入れようと思ったらいつの間にかサーバがダウンしていたでござる。
プロビジョニングってそういうものだったっけ…。
＃泣きながらPerlでコード書くほうが時間も手間もかかるけど気楽だな…。
その後
ようやくシェルが復帰したからPSみたら、大量のmakeとgcc44-c++を走らせてるご様子。一体ゾンビがいるからお仕事は継続してたんだろうけど、ここまでコンパイルでパワー使うとか思わないぞフツー…。
丁寧にプロセス一個づつ殺してってようやくきれいに。
…マジでそんなコンパイルするのかこいつ。弱ったなぁ…X落としてから再挑戦かな…。
無能なるblog
猿はシェイクスピアをタイプできるか
