Chef

個人と仕事のサーバはどちらも Knife-Solo で構成管理しています。 Chef がバージョンアップしたら、私はなるべく knife solo prepare し ていますが、このコマンドは単純実行すると、サーバの台数に比例して時 間がかかります。 Knife-Zero でそれを解決できるのかなと思い、Getting Started してみ ました。 結論 代替にはならない。knife zero bootstrap も knife solo prepare と同 様、Chef をインストールするのは同じ。 Home(ja) · Knife-Zero まずKnife-ZeroはKnife-Solo の乗り換え先ではありません。 仰る通りでした。 勘違い loading... 勘違いみたいですね。誰もツッコんでくれなかった…。( ；∀；) Knife-Solo は chef-solo gem ではなく chef-zero gem と依存関係があ るから、ずっと使えると思っていたけど、大きな勘違いだった。 そもそも chef-solo gem は存在しない。chef gem に含まれる chef-solo コマンドが存在するだけ。 Knife-Solo は chef-solo コマンドを使って Cook する。chef-solo コマ ンドはいずれ引退するので、いずれかに乗り換えが必要。 で良いよね？（まだ不安） 今後の予定 個人サーバは素振りも兼ねて Knife-Zero に移行する 静的サイトなので Docker 化しても良いけど、このサーバは仕事の...

knife-solo v0.5.0 から –forward-agent オプションを付けないと、 Cook に失敗するケースがありました。 例えばこのように指定します。 bundle exec knife solo cook ci-docker ↓ bundle exec knife solo cook ci-docker –forward-agent 変更があったのはこちらの PR https://github.com/matschaffer/knife-solo/pull/394 knife-solo では sudo が使われますが、v0.5.0 から –forward-agent オプションを付けた場合だけ -E オプションが付くように変更されました。 sudo の -E オプションはこのようなものだそうです。 -E, --preserve-env Indicates to the security policy that the user wishes to preserve their existing environment variables. The security policy may return an error if the user does not have permission to preserve the environment....

サーバの CI ってどうするのが良いのでしょうね。現状やむを得ず行って いますが、やり過ぎ感も否めないです。 [2014-09-14-1] に Wercker+Vagrant+EC2 の組み合わせでこのサーバの CI を始めてから、[2015-02-08-2] に CircleCI+Vagrant+EC2 に変更しま した。そして今回、CircleCI+Docker に変更しました。 理由は EC2 を使うのは大げさだと思い始めたからです。CI 時間の短縮を 期待しましたが、ほとんど変わりませんでした。結果的に、時々 EC2 イ ンスタンスを起動するのに 30 分以上かかり、CircleCI のタイムアウト 時間を超える問題は解決出来ましたが。 Docker 入門できて自己満足は得られたのですが、Docker の使い方ではな いなあというのが正直な感想です。 Docker を使ってサーバの CI をするためには、openssh-server をインス トールする必要があります。そもそも Docker は一度インスタンスを作っ たら変更を加えるべきではないため、Docker を起動してから knife-solo で変更を加えるのは誤った使い方です。 このブログのサーバ（さくらの VPS）には nginx や td-agent、 elasticsearch などがごちゃごちゃと入ってますが、同じ環境を Docker で作るのもおかしな話です。Docker は 1 サーバ 1 責務だと思うので、 例えば nginx だけをインストールする使い方が正しい気がします。 そういう意味で無理して CI しているなあと、モヤモヤしているところです。 修正内容はこちらです。末尾に解説を記載しました。 ./script/bootstrap-docker.sh このスクリプトは CircleCI の dependencies.pre で実行されます。...

Ubuntu 14.04 LTS + nginx 1.9.3 の環境で、knife solo 経由での nginx reload が出来なくなっていました（Chef のバージョンは 12.4.1）。 サーバの CI では nginx start のみが実行され、nginx restart は実行 されないため、気づけなかったようです。 レシピは至って普通。 service 'nginx' do action [:enable, :start] supports status: true, restart: true, reload: true end template '/etc/nginx/sites-available/masutaka.net' do notifies :reload, 'service[nginx]' end /var/chef/cache/chef-stacktrace.out にはこんなエラーが。 Generated at 2015-07-26 01:10:55 +0900 ---- Begin output of /sbin/reload nginx ---- STDOUT: STDERR: reload: Job is not running: nginx ---- End output of /sbin/reload nginx ---- Ran /sbin/reload nginx returned 1 実際、そうなりました。よく分かりません。...

ufw = Uncomplicated FireWall です。 レシピはこんなのを作りました。opscode のレシピとか使うと、何設定し ているか分からず結局全部読むことになるので自前で書いてます。 execute 'ufw reload' do action :nothing end execute 'ufw default deny' do not_if 'ufw status verbose | fgrep "Default: deny (incoming)"' notifies :run, 'execute[ufw reload]' end execute 'ufw allow http' do not_if 'ufw status | egrep "^80 +ALLOW"' notifies :run, 'execute[ufw reload]' end execute 'ufw allow ssh' do not_if 'ufw status | egrep "^22 +ALLOW"' notifies :run, 'execute[ufw reload]' end execute 'ufw enable' do command 'yes | ufw enable' not_if 'ufw status | fgrep "Status: active"' end serverspec はだいたいこんな感じです。...

[2014-01-09-1] からWerckerを使い始めて1年とちょっと。このたび CircleCIに移行しました。理由は以下のとおり。 会社のJenkinsが壊れてCircleCIを使い始めた。2つ覚えているのが面倒 [2015-01-25-1] の継続的bundle updateをやりたい(WerckerはAPIがないっぽい) [2014-01-09-1] 当時と違いCircleCIは1コンテナまで無料になった Werckerは自分のBoxを簡単に作れたのが良かったんですけどね。 (masutaka/wercker-box-rvm-vagrant-aws の更新は停止します。) 特殊なことはしていないので、Vagrantfileとcircle.ymlを晒すだけにし ておきます。 CircleCIはコンテナにsshログイン出来るのは良いけど、EC2インスタンス が起動されてそのままになるような。。。さっさとDockerに移行しないと。

前回[2015-01-09-1] はBerksfileにGitリポジトリを直接書きましたが、レ シピの依存関係の解決ができませんでした。 berkshelf-apiサーバを立てるとその問題が解消されるようなので、 Herokuにberkshelf-apiサーバを立てて検証してみました。 適当なOrganizationを作り $ berks cookbook git . などで作ったcookbookを用意します。gitのtagを振る必要がある点は注意です。 https://github.com/doramichan/git/releases https://github.com/doramichan/hub/releases berksコマンドは $ gem install berkshelf などでインストールできます。 hubレシピはgitレシピに依存させた ため、Berksfileに cookbook ‘hub’ と書けばgitレシピもインストールされるはずです。 ※適当なレシピなので動作は保証しません。 次にapiサーバを用意します。Heroku stackがcedar-14だと動かなかった のでcedarに変更しています。LD_LIBRARY_PATHの追加はREADME.md の説明 のとおりです。 $ git clone git@github.com:berkshelf/api.berkshelf.com.git $ cd api.berkshelf.com $ heroku create -s cedar masutaka-api-berkshelf $ heroku config:add LD_LIBRARY_PATH=/app/vendor/libarchive-3.1/lib $ git push heroku master 続けてconfig.jsonを追加し、先ほどのdoramichan Organizationを参照さ せます。 { "endpoints": [ { "type": "github", "options": { "organization": "doramichan", "access_token": "YOUR GITHUB ACCESS TOKEN", "api_endpoint": "https://api....

Chef-solo(Knife-solo)とBerkshelfの話。 Berksfileに例えばこうやって書けば使えた。これは有能！ relってサブディレクトリのことだったのか。Gemfileで使ったことなかった。 cookbook ’nginx’, git: ‘git@github.com :masutaka/cookbooks.git’, rel: ’nginx’ $ bundle exec berks vendor vendor/cookbooksを実行すると、 vendor/cookbooks/nginxにインストールされる。 .chef/knife.rbを以下のように変更すると、インストールしたnginxレシ ピをnodeやroleから参照できる。ちなみにcookbook_pathは後ろから先に 参照される。$PATHの逆。 cookbook_path [“cookbooks”, “site-cookbooks”] ↓ cookbook_path [“cookbooks”, “site-cookbooks”, “vendor/cookbooks”] ※ .gitignoreに/vendor/cookbooksの追加も忘れずに。 private repositoryの時はこの書式は使えなかった。やり方はあるかもし れない。 cookbook ’nginx’, github: ‘masutaka/cookbooks’, rel: ’nginx’ 今までは https://github.com/masutaka/cookbooks とかをGitのsub moduleとしてガッツリ指定していたため、追随するのが大変だった。 cookbooksを変更する人も気を使ったし。 この辺の話に関連する。 JenkinsでサーバのCIを始めました｜feedforce Engineers’ blog Berksfileの書き方は公式ドキュメントに書いてある。 http://berkshelf.com/ 追記: 依存関係(metadata.rbのdepends)は見てくれなかった。そりゃそうか。 継続調査。

[2014-09-14-1] に書いたとおり、このmasutaka.netではサーバのCIをして います。 今までテストが通ってから、手動でCook+Serverspecして不便に感じてませ んでしたが、試しにWerckerのデプロイ設定をしてみたら、案外便利でよく 使っています。 wercker.ymlはこんな感じです。 管理画面からDeploy targetを作る必要があります。ちょっと管理画面が古 いですが、こちらを参考にしてください。 wercker + Capistrano で自動デプロイ - milk1000cc’s blog 私はTarget nameをProductionにして、SSH keysで作った鍵を $WERCKER_SSH_KEY_PRIVATEという名前でwercker.ymlから参照できるように しました。 ブラウザからWerckerのサイトに行くのが面倒だけど、個人でChatOpsやっ てもなあ…。とはいえ、やるかもしれませんが。

[2013-05-19-1] にインストールしたUbuntu 12.04はうっかり32bit版でした。。仕方がないのでUbuntu 14.04へのアップグレードがてら、クリーンインストールすることにしました。 管理画面からポチポチしてOSのインストールは完了。CookはあらかじめVirtualBoxとEC2で確認していたので万全です(ｷﾘｯ と思いきや、いつまでたってもRecipeが処理されません…。 $ knife solo cook masutaka.net Running Chef on masutaka.net... Checking Chef version... Uploading the kitchen... Generating solo config... Running Chef... Starting Chef Client, version 11.16.2 (ここでダンマリ) これまた仕方がないので、サーバ側の/opt/chef/embedded/lib/ruby/gems/1.9.1/gems以下をprintfデバッグ(というかpデバッグか)で調べたところ、Chefがサーバ情報を取得するときに使うOhaiのGCEプラグインから返ってこないことがわかりました。GCEとはGoogle Compute Engineです。なんでChefが？ で、結論から言うと、GCEプラグインをOFFにしたら解決しました。 knife solo prepareのあとに/opt/chefが作られるので、/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-7.4.0/lib/ohai/config.rbを以下のように修正。あとはknife solo cookするだけです。knife solo bootstrapは出来ないことになります。 default :disabled_plugins, [] ↓ default :disabled_plugins, [:GCE] knife soloはchef-soloをリモートから実行するコマンドで、 /opt/chef/embedded/bin/ruby /usr/bin/chef-solo -c /home/masutaka/chef-solo/solo.rb -j /home/masutaka/chef-solo/dna.json のようなchef-soloコマンドを実行します。root権限だったかな？ この/home/masutaka/chef-solo/solo.rbに Ohai::Config[:disabled_plugins] = [:GCE] を書き、前述のchef-soloコマンドを実行すれば/opt/chef以下を修正する必要はありませんが、残念ながらこのファイルはknife solo cook時に自動生成されます。 ローカルの.chef/knife.rbに書いても無視されました。残念。そういうわけで、今はprepareをした後はサーバにログインしてファイルを書き換え、そのあとにcookというイマイチなことをしています。 ではなぜ、さくらのVPSだけダンマリになるのか？ /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-7.4.0/lib/ohai/mixin/gce_metadata.rbのここに違いがありました。 def can_metadata_connect?...