ページ

2015年1月31日土曜日

山に来てBoxenやめてAnsibleにしました

気がついたら前回の退職エントリーから10ヶ月ぐらい何も書いてなかった。よくない。
最近あんまりネットにいませんね、とか(元々そんなにいなかったのに)言われるようになってた。よくない。

初心に立ち返って、環境構築のこと書く。
具体的には、boxenをやめてansibleにした話。

boxenを使ってきたけど、結論としては個人の環境構築に使うにはtoo much。使い始めた時点でうすうす感じてはいたことだった。
なんか一個brew upgradeしたいだけなのにpuppet moduleに手を入れなきゃならないのはコストがかかりすぎだし、boxen自体をour-boxenからfetchしてmergeしてアップデートしていくのもダルいし、それを他のところ(チームとか)でも使うならまだしも、自分しか使わないのであれば、新しいパソコンに毎回環境構築するほうが楽だと思った。
あとは、色んなものが/opt/boxen/の下に入るのがちょっと気持ち悪かった。brew installした時のインストール先とかわかりにくかった。

そんな感じでbrewfileにでも移行しようかと思っていたら、使ったことないうちにオワコンになってた。
じゃあどうすっぺーかと思っていたところで、今をときめくansible(僕の中で)をlocalで実行するという手があるとわかったので、そうすることにした。


boxenのhomebrew使ってた場合はboxen消すとhomebrewも消えるので、ansible導入後にまたbrew installするものはbrew listとかで洗い出しておくといい。

boxen関連のものを完膚無きまでに削除

$ /opt/boxen/repo/script/nuke --all --force

改めてHomebrewとAnsibleをインストールする

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ brew install ansible

ansibleをローカルに実行したい場合、playbookのhostsに127.0.0.1を指定してやって、実行時に--connection=localをつけるか、playbookにconnection:localと書いてやればssh経由でなく実行される。
参考: http://docs.ansible.com/playbooks_delegation.html#local-playbooks

そういうわけであとはplaybookを作って育てていけばいい。大抵の場合はlocalhost.ymlが1ファイルあるだけで事足りるんじゃないだろうか。

inventoryファイルに関しては普通に作ってやってもいいし、ansible-playbookするときに -i "localhost," とかつけてやると作らなくても済む。

あとはlocalhost.ymlを育てていけばよい。


適用するときには
$ ansible-playbook localhost.yml -i "localhost," --ask-sudo-pass
のようにすればよし。

たぶん、最初から入ってないと大幅に使い勝手が変わったり困ったりするものって僕の場合はそれほどないので、それ以外のものは必要に応じて手で入れるようにして、dotfileとかtmuxとか、インストールして設定するのがめんどいものを自動化しておくのがいいバランスなんだろうと思う。

2014年4月13日日曜日

僕も株式会社リコーを退職しました

3月末でリコーを退職しました。
退職エントリーって人生であまり書く機会なさそうなのでせっかくだから書いておこうと思うのだけど、自分がいた会社を悪く言うのもなんだし、どう書いても後ろ足で砂をかけることになりそうでなかなか難しい。
念のためにお断りしておくと、ここに書くことは、あくまで大きな会社の元一社員としての僕が感じた事実であり、それ以上でもそれ以下でもありません。


2011年の4月に学部の新卒で入社して、今年の3月末で退職したので、ちょうど丸三年勤め上げた。案外長くいたと思う。

辞めた理由は色々あるけど、そもそも入社する前からあまり長くはいないだろうなってことはなんとなく思っていて、その気持ちを覆すようなテンションの上がることが最後まで起こらず、逆に、ああこれはもう辞めようと思わされるようなことはたくさんあって辞めるに至ったので、どちらかというと辞めない理由がなかったというほうが正しい気がする。

少なくとも、あのまま居続けてもどうにもならないし、何者にもなれないどころか、なりたくもない何かになってしまいそうな感じがしていた。
これは主観だけど、決して優秀ではない僕が、部署においては優秀な人の部類だったであろうことは全く嬉しいことじゃなかった。この人には一生かかっても追いつけない、と思える人が失礼ながら周りにはいなかった。会社全体でみればきっといたと思うけど、割合として少なすぎるのと、そういう人がきちんと評価されているようには見えなかったので、会社に残る理由にはならなかった。

会社に対しては大小様々思うところはあって、抱えてる問題をどう解決すべきかとかも考えたし、多少実践もしたのだけど、そもそもそれを問題だとも思っていない人たちの中で解決しようとするのが本当にいいことなのかわからなかったし、僕から見れば明らかでしかないことを指摘したときに、それは気づかなかった、と感心されるような状況は、言ってしまえば面倒でしかなかった。長い目で見れば会社のためになる、という思いを持てるほどの愛社精神は持ち合わせていなかった。

具体的な話は、会社を辞めた今ではもはや愚痴になってしまうので書かないけど、大企業病の症状みたいなものを挙げていけば大抵当てはまると思う。
この前話題になってた下の動画みたいなことが、エンジニアとしてだけでなく、常にあらゆる場面で起こっていた(この動画に関しては、エキスパートの人にも多少問題があると思ったけど)。



そうは言っても悪いことばかりじゃなかったでしょ?って聞かれたら、確かにそうなのだけど、そういう時に、じゃあよかったね、って全てをよしとしてしまう風潮があったのが、何よりも問題だったのかもしれない。


そんなわけで、今は山でくもを眺めています。




先日こんな記事↓があったからタイトルに「僕も」と付けたけど、この人とは何の面識もありません
株式会社リコーを退職しました - 月曜日までに考えておきます

2014年1月2日木曜日

Boxenの導入

準備が出来たので、Boxenを導入する。

前提として、Xcode Command Line Toolsがインストールされていること。
(Mavericksの場合はBoxenがいいようにしてくれるっぽいが、僕の場合は既にインストールしてあったので実際どうなるのかわからない)

https://github.com/boxen/our-boxen#bootstrapping に書いてある通りにやっていく。

あらかじめどこかに自分のboxen用のgitリポジトリを作っておいてから以下を実行。
sudo mkdir -p /opt/boxen
sudo chown ${USER}:staff /opt/boxen
git clone https://github.com/boxen/our-boxen /opt/boxen/repo
cd /opt/boxen/repo
git remote rm origin
git remote add origin <自分のリポジトリ>
git push -u origin master

用意されたモジュールだけで事足りる人はむしろ少数派だと思うので、必要に応じてPuppetfileの末尾に利用するモジュールを追加してやる。
大抵のメジャーどころはhttps://github.com/boxenにある。

Puppetfileはダウンロード元等の定義に過ぎない。Puppetfileに続いてmanifestを編集する。
globalな設定はmanifests/site.pp に、personalな設定はmodules/people/manifests/githubのユーザー名.pp に書く。この辺は仕様ではなく流儀。

(んーしかしPuppefileの存在意義ってなんなんだろう。上みたいな形でグローバルな設定と個人の設定は切り分けられてるわけで、各種定義もそこでやればいいのでは……)

これで
cd /opt/boxen/repo
./script/boxen
すれば諸々インストールやら設定やらされる。

尚、デフォルトだとFileVault使ってディスクを暗号化することを要求される。それが嫌な人は--no-fdeをつけてやればいい。
./script/boxen --no-fde

.bashrcか.zshrcが既にある場合は、以下を追加する
[ -f /opt/boxen/env.sh ] && source /opt/boxen/env.sh

シェルを新しく開いて、boxen --envがちゃんと動けば正しくできてる。動かなければ頑張る。

参考: Boxenを利用したMacのセットアップ | iii ThreeTreesLight

2014年1月1日水曜日

Boxenの導入(の準備)

新年、明けましておめでとうございます。

今年一年を良い年にすべく、Boxenを使ってみることにしました。


準備


boxenと干渉する可能性があるものをアンインストールする。
僕の環境ではrbenv, homebrew, nvm。なんとなく影響が小さそうなものから消していく。

nvmのアンインストール

公式にアンインストール方法が書いてなかった。

とりあえず.nvm/を消す。
% rm -rf ~/.nvm
あとは.zshrcにも数行書いてあったのでそれも消した。

rbenvのアンインストール

rbenvはbrewでインストールしたので、homebrewごと消せばいいのかもしれないけど、一応ちゃんと消す。

rbenv管理のrubyを消すには、~/.rbenv/versions/ の中にあるディレクトリを消すか、ruby-buildを使っているならrbenv uninstallで消せる。
これもわざわざやらなくていいような気はしたけど、パッチレベルも低かったのでついでに消した。

で、rbenvとruby-buildをアンインストール。
% brew uninstall ruby-build
% brew uninstall rbenv
% rm -rf ~/.rbenv
なんかよくわからないけど一回やっただけだとちゃんと消えず、何回か実行したら消えた。

homebrewのアンインストール

https://github.com/Homebrew/homebrew/wiki/FAQに書いてあった、このスクリプトを使った。

実行したら何故かiTermのタブが閉じたりしてちゃんと消えたのかよくわからない。
which brewとかしてcommand not found: brewとか出るようになったので消えたと信じる。

これでようやく準備が整った。

2013年10月17日木曜日

capistranoでmiddleman buildするまで

前回、bundle installするところまで出来たけど、その後middleman buildもして欲しかった。

capistranoでやる以前に、そもそもUbuntuでmiddleman buildしようとすると、execjsがjavascriptのruntimeが見つからないと言って泣いていた。
幾つかの依存ライブラリが足りないらしいので、Gemfileに以下を追加
gem "rb-inotify"
gem "therubyracer"

これでmiddleman build自体は出来るようになったので、今度はcapistranoでやるように、deploy.rbを編集。
capistrano-bundlerのソースとか見よう見まねで、こんな風になった。


withinとか要らなそうだったり、executeが2行に分かれてたりとか、若干気に入らないところはあるけども、ともあれこれでbundle installの直後にbundle exec middleman buildされるようになった。

2013年10月14日月曜日

capistranoでbundle installするまで

今回はいつにも増して個人の覚え書きです。

この度、初めてcapistranoを使ってみようと思ったら、ちょうど3.0.0が出たばっかりのタイミングだったらしく、ググって出てくる情報が微妙に役に立たなかった。
2.x系は使ってないのでわからないが、2から3へのアップグレードについては http://www.capistranorb.com/documentation/upgrading/ とか見ればいいと思う。

インストールは普通に、gem installするか、Gemfileに書いてbundleする。

プロジェクトの初期化的なことをする。
$ cap install
bundlerでインストールした場合はbundle execをちゃんと付ける。(後で出て来るcapistrano-rbenvを使おうとした時に、この辺の話でしばらくハマった)

cap installすると、Capfileやら何やら色々生成される。

deploy.rbやらproduction.rbやらに目を通すと、よくわからないDSLが書いてあるので、ちょっと読んで嫌な気持ちになる。

role :appとか3つぐらい書いてあるところがあるが、僕の場合サーバーは1個しかないので server で代用できる。

あとはdeploy.rbの:application、:repo_url、:deploy_toぐらいを書けばたぶん最低限のデプロイはできる。(set :scm :gitは書かなくても動いた)

$ cap
だけだと、Stageがセットされてないって文句を言われるので、
$ cap production deploy
とか、してやる。


bundle installもして欲しいので、続いてcapistrano-bundlerを使う。
gem installもしくはGemfileに書いてbundle。

Capfileで
require 'capistrano/bundler'
すれば、deploy:updatedの前にbundle installしてくれるはず。

が、エラー。
/usr/bin/env: bundle: No such file or directory

原因は、サーバーでrbenvを使っていて、capistranoはsudoでコマンドを実行するため、sudo /usr/bin/env だとrbenvのgemとパスが違ってしまうこと。
サーバーのbashrcとか/etc/sudoersとかを書き換えたり、Capfileでset :use_sudo, falseとかしても駄目だった。

そこで、capistrano-rbenvというものがあるのでそいつを使う。
rubygems.orgにホストされているのは古いので、ソースにgithubを指定してやる必要がある。
(僕の場合、前二つをgem installして、ここでGemfileに書くようにしたため、bundle execつけずに実行してワケが分からなくなった)

Usageを見ると
require 'capistrano/rbenv'

set :rbenv_type, :user # or :system, depends on your rbenv setup
set :rbenv_ruby, '2.0.0-p247'
をCapfileに書くか、rbenvのパスによってはrbenv_custom_path使え、と書いてあって、僕が使ってるUbuntuでは実際rbenvのパスがcapistrano-rbenvのデフォルトと違ったので、
set :rbenv_custom_path, '/opt/rbenv'
を、rbenv_typeの代わりに書いてやった。

これでようやく、デプロイしてbundle installされるようになった。

2013年8月11日日曜日

Chefからufwを有効にする

execute resouceを使った。

ufw enable と ufw allow sshしている。

sshでufw enableしようとすると、sshのコネクションが切れるかもしれないけどいい?(y|n) みたいな確認をしてくるので、パイプでyesを渡してやっている。
手元でvagrant使って試したらこれでいけたけど、allow sshが先に実行されるようにしたほうがいいのかもしれない。

chefはknifeとかcookbookとかの用語とDSLで、学習コストを飛躍的に高めてしまっていると思う。