2013-10-31

英語で検索しづらいchef vs ロゴがイマイチなansible

■まえがき

構成管理ツールが便利だよねっていう話を数年前から良く聞いていて、僕みたいな別にインフラ専門じゃないエンジニアでも使うようになる時代がやってきました。

個人的な話ですが、主な用途はvagrantへのミドルウェアデプロイです。まっさらなVMに必要なものをインストールしたりするだけで、目的が浅いw(設定ファイルとかはデフォww)


今回はchefとansibleを両方触ってみて、色んな人の記事を見た上で色々比較してみようと思います。
ただ、できることは両方やろうと思えば出来ると思うので、アレが出来ないこれが出来ないっていう比較はマサカリ怖いのであまり書かないようにします。。(わかってないなと思ったらやさしく教えてください><。)

というわけで今回比較すべきはとっつきやすさと運用方針の観点から比べてみたいなと思いました。


■それぞれの特徴比較

下記スライドがわかりやすかった。22ページ目に比較図。


資料から、ざっくりchefとansibleにフォーカスすると

・Chef

- Ruby製
- 各サーバにインストールして利用
- DSLで自由度高い書き方
- Opscodeの共有リポジトリがある

・Ansible

- Python製
- 標準モジュール意外と多い(http://www.ansibleworks.com/docs/modules.html)
- push型:sshできればおk
- 構成がシンプル:YAMLで設定書く
- 共有リポジトリ無い

▼個人的な見解

yamlは特定の言語ってわけじゃないからDSL覚えるよりはるかに楽だった。自由度も構成管理する上では手順かければいいくらいなのでそんなに要らないと思う。
ansibleは公式の共有リポジトリが何故か無かったりする。
けど、gitとかでチームが管理すれば良いかなとか思ったり。
最近だと共有してるyeoman-generatorでvagrantとansibleをテンプレ化してローカル環境構築みたいなのをやったんだけど楽。


■とっつきやすさ


好きな方を選べばいいと思う。

・主な編集ファイル

chef:rubyのDSL(自由度高い)
ansible:yaml(記法さえ分かれば使える)

・ファイル構成

chef:多い。覚えるの大変。
ansible:最小構成で1〜2ファイル。ベストプラクティスがあるけど、いわゆるファイル分割してるだけでわかりやすい。

・手間

chef:実行環境準備はchefのほうが多い。あれもできるよこれもできるよってなるときりがないけど、最初から出来る機能で評価するには面倒くさいというイメージ。
ansible:デフォルトの実行環境1回作ったらsshつながるサーバなら大体動く。やりたいことを実現するまでの過程が超シンプル。これが大事なんじゃないか。



■運用の観点からどちらを選ぶか

大規模運用だったらchef-serverとか高機能なものが用意されてたり、そういう管理がしたい時はchef。
Facebookは大規模な管理向けにchef採用してたりする。

ansibleはplaybookの共有だけで、とりあえずサーバ構築が可能。ベストプラクティスを参考にすれば大規模運用な設定も出来るはず。
yamlだから、複雑なことするときにはちょっとコツが居る。

▼個人的な見解

そんなデカい運用してたらその運用が大変なのでやっぱり簡単な方がいいな。
個人用途なので断然ansibleが楽。インフラ専門ならchefくらい使われてるモノのほうがいいのだろうか。両方出来なくは無いんだろうけど。


■web上での評判

色んな記事から評判で比較してみました。

・chefが辛くてansible使ってみた人
→chefは独自概念が多かったり、対称ホストへのインストールが発生したり面倒なイメージが強い。ドキュメントが豊富なんだけど、使える様になるまでの学習コストが高い。

・chefとansibleを両方使い込んでる人
DSLかyamlかみたいな比較。最終的にはそんな凄いことやらないじゃんってなって、もし複雑なことする場合はモジュール自作してansible使えばいいじゃんという落ち着き方。

・個人ツイートのnaverまとめ
ansibleはpythonな人にオススメ。chefとの比較はやりたい手順を書く方法としてどっちが楽かという問題。

・chef vs ansible談義
色々あったけど、どっちもやろうと思ったことはできるね。

・Ansible使ってみた人の意見

"Chefの場合ですと、knife-soloを利用する事で、Push型に似せた実行が出来るのですが、やはりプラグインを追加でインストールしなくてはならない上に、あくまでPush型ライクな実行ができるだけにとどまっています。"
→ansibleの強みはansibleだけのものじゃないけど導入は面倒


▼個人的な見解

ansible寄りな記事を集めてしまったせいなのか、情報操作してる感がして比較ではなくあくまで参考にして欲しいw

pythonならansible!っていうのも実行環境の問題だと思うんで、python別に書けなくても使える。yamlがなんなのか知らないとだけど、xmlみたいな記述してくだけのものなので勉強するとかそういうものじゃないと思う。

あとDSLだと自由度が高いよ!っていうのもいいとは思うんだけど、やっぱりそこにたどり着くまでが大変だし、そのレシピって結構めんどくさいことやってんなぁと思ってしまう。
ansibleのシンプルに書くことを前提とされてるyaml形式がいいと思うし、もし複雑なことしたいときはモジュール自作っていう手もあるしね。


■まとめ


「今からやるならansible。」だと思う。

ようこそansible教へ!
chefは独自概念が多い。対してansibleはyamlとホスト指定するファイルだけで動いちゃう。本当にシンプル。モジュール一覧見る限りだと、結構なんでも出来る。
思いつくデメリットはansibleは変数出し分けが他に比べてやり辛いかも。ベストプラクティスを参考にしてもちょっとコツが居る。

大規模運用をansibleでやったって事例があれば見たい。bashoとかevernoteとかが使ってるみたいだし大丈夫なのかな?
シンプルなのが好きだし学習コストってトコではansibleでいいんじゃないかと思う。本とか無くてもすぐ使いこなせるし。
よりシンプルで覚えやすく、やりたいことがそれなりに出来て、大規模運用も厭わない。

過去のリソースにそんなにとらわれないならansible。
ちょっと使えるようになるまで時間がかかるけど、やりたいことはなんでも出来て大規模運用でも大丈夫。過去のリソースが豊富な方が嬉しいならchef。
chefはchef屋さんにならないとダメだけど、ansibleはライトユーザーでもぱっと見で使いやすいので、開発環境の導入だったりその延長で本番環境の構築だったりで使うにしてもansibleは便利。

rubyDSL覚えるよりyamlの見方覚えるほうが楽。むしろ覚えなくてもサンプルみたら記法とか気にせず使えちゃうと思う。それくらいシンプル。

yamlだと自由度低いとかになってるけど、あんまり経験がないのでなんかインストールしたり決まった設定ファイル配置したりする程度だったらansibleでおkだと思う。
その他こういう時yaml困るぜ!ってのがあれば教えてください!!

2013-10-26

Mac OS X 10.9 Marvericksでgrunt-contrib-watchが動かなくなった

GruntJSいいですよね。
watchしてstylusのコンパイルを自動でやったりしてたんですが、macをMarvericksにアップデートしたら動かなくなったけど直ったのでφ(`д´)メモメモ...

現象

Running "watch" task
Waiting...Bus error: 10
↑こんな感じになります。

対策

Node.js v0.10.20を使ってたんですが、これだと動かないぽい。
v0.10.21からなら動くらしいので、以前入れたnvmでv0.10.21をインストール。

$ nvm install v0.10.21
$ nvm use v0.10.21
これでOK。
と思ったらgruntやらなにやらグローバルインストールしたものも入れなおさなきゃいけないのでnpm install -g grunt-cliしといた。

これで完了。動作確認おk。

まとめ

githubのissue嫁



2013-10-21

79は今何をしているのか?

社内ニートアピールがうざいとか思われてるかもだけど、仕事はしてますアピール。

仕事とかプライベートで使ってるものが多くなってきたけど、それぞれの記事をブログに書くまでの時間がないので意識高めるためにもリストアップしておく。誰かのブログを参考にしてますw時間があれば記事も書く。同じことやってたりして質問とかあれば聞いて下さい。

■仕事

Vagrant

下のAnsibleと連携して使っている。最近だとyeomanのgeneratorとしてvagrantのテンプレート作って、それをyo→vagrant upだけで開発環境構築完了する。爆速(Ansibleのインストールは遅い)。

Ansible

vagrantを構築して、そこにCassandraとかぶち込むために使ってる。npmリポジトリからインストールさせたり、gitからcloneさせたり、色んなモジュールが揃っていてやりたいことがplaybook.ymlだけで全部書ける。
そしてChefとかより断然シンプルなので、ちょっとした構成管理ツールとしては最高だと思われ。学習コストも低い。

Cassandra

担当していたゲームのメインデータストア。というかこれ一本。実際は直接CQLでデータ呼び出しがあるわけでは無いのでプロジェクトの実装時にCassandraをあまり意識しないで使えたりしたけど、データ構造・データ設計などコツがいるので良い経験になった。
cqlshでcql叩いたりとかはちょくちょくしている。

yeoman

順番がおかしいけど最初に言ったVagrantのテンプレ作ったり使ったりするために使っている。vagrantだけじゃなく、Node.jsのプロジェクトもyeomanで一発生成できるようになってる。めっちゃ簡単。シンプル。

JavaScript

サーバサイドからクライアントサイドまで全部JavaScript漬け。どっち書いてるかわからなくなるレベル。Javaも2年だけやったけど、こっちに慣れるとサーバサイドをわざわざJavaで構築しようと思え無くなる。それくらい楽。
クライアントサイドはtofu.jsという社内のライブラリを使ってActionScript風に書いていた。DOM操作ほぼ無し。
Node.js周りが凄く活発なので、Github眺める時間が増えた。しかしまぁ社内の主席エンジニア様のソースコードが一番勉強になる。


■プライベート

▼サイト制作

yeoman (主にGrunt)

yo, bowerはあんまり使ってない。というか最初しか使ってないだけだけど。
タダのシンプルな静的ページ作るときに、stylus使ってcss書いて、js圧縮してくっつけて、画像最適化して〜と盛りだくさんでやってみた。

stylus

流行ってるSassとかLESSとか触ってみたかったので、一番良さそうなstylusにした。
書き方は楽になったけど、まだ上手く使い切れてない。社内のstylus使ってるプロジェクトを教えてもらったので参考にする。

JavaScript

仕事でやってたクライアントサイドはDOMをあまりいじらなかったけど、コッチは一般的なDOMいじりの方。JavaScript初めてから最初はBackbone.js使ったプロジェクトだったりしたんだけど、それ以来使っていなかったのでリハビリがてら。

jsHint

カスタマイズしたものを仕事でのチームで共有する使い方が気に入ってから自分でも使っている。これ使ってない人とは仕事出来ないレベル。

vim-airline

powerlineのセットアップがめんどかったのでコッチにした。キレイ。

WordPress

感覚で使っている。phpをテンプレートエンジン代わりに使っているというか、phpがフロントエンドに大量に書かれているプロジェクトの巻取りなので正直関わりたくないけどざっくり理解して使っている。カスタマイズ製高くて使いこなしているぽいプロジェクトだったのが勉強になってまぁいい感じ。
多機能で良いんだけど、面倒くさいところが多いイメージ。


▼ネイティブアプリ制作

cocos2d-x

C++を使うiOSとAndroidに対応したクロスプラットフォームな開発環境。正直まだあんまり触れていないけど、ひと通りAPIを使っているコードは追ってみた。C++も学生ぶりに触っていて、ゲームとして組み上げるのは時間がかかりそうだけど、サイト制作終わったらすぐやりたい。

Photoshop

当たり前なんだけどネイティブアプリはCSSとか無いので画像が必要になる。
素材も自分で作る。まだ初心者。CC会員登録したよ。Flashとか使ってみたい。
闇デザイナーを目指す。


■今後触っていくもの

angular.js

Backbone使ったからあんまり抵抗はない。会社で使いそうだから様子見してる。

OpenFrameworks

インスタレーション作品とか一度は作ってみたいよね!


まとめ

抜け漏れありそう。わざわざ書いてないだけのものもある。herokuのredis使ったーとか。メンドイ。
こういうとりあえずやってる物書くだけってなんか良いな。定期的にやりたい。

こんな感じで最近は環境構築周りのツールとか、実際にプロジェクトを作っていく作業も作業もやってたりする。
新しいものが色々あるなか、どんどん使っていきたいし、それを作る側にもなりたい。
隙を見てpull request送るとかそういう活動もどんどんやっていこう。

2013-10-18

筋トレしたら痩せるのめっちゃ楽なんですけどwwwwww

最近何を目指しているのかわからないくらい筋トレしています。
一般的な健康な身体を目指すつもりが、気づけば趣味を超えて精神の鍛錬になっていました…。

その中で食事が一番大事、かつ難しいところだったのでメモ。

目的別フェーズについて


大きく分けて

1. とにかく鍛えながら体重を増やすフェーズ
2. 脂質と糖質を制限して無駄な脂肪を燃やすフェーズ

の2つに分けられます。
フェーズごとに説明していきます。

1. とにかく鍛えながら体重を増やすフェーズ


トレーニング開始時点では180cmで60kgしかない状態だったので、週2〜3回のトレーニングに合わせてとにかく食事を取ります。
出来るだけ肉、タンパク質。腹減る事は悪。一日に4〜5食はとっています。

この時はなるべく油ものや、麺、麦は選ばない様にしてます。しかし他に選択肢がなく、腹減るくらいなら食べてもOK。
こうする事で、トレーニングの効果を100%筋肥大に与えていきます。食べ過ぎて脂肪が付くくらいが丁度良いのです。

この生活を半年近く続けて60→69kgまで増やしました。身体つきも変わってきます。

・1の失敗

本来はもっと体重を増やしてから2の脂質と糖質を制限するフェーズに入ります。
しかし良いと思って動物性タンパク質を中心にとる生活をし、健康診断の結果LDLコレステロール値が高くなってしまいました。
脂肪も今までに無いくらい付き、腹が出てモチベーションが下がってきます。

モチベーションはとても大事です。
挫折する前にトレーナーと相談し、身体を絞る次のフェーズに移行することにしました。


2. 脂質と糖質を制限して無駄な脂肪を燃やすフェーズ


ここからはダイエッター向けの内容になります。

・痩せる理論

痩せる方法として、基礎代謝を上げるのが一番効率が良く、リバウンドが無い方法です。
筋トレをして筋肉をつけて代謝を上げ、日々の生活の中で脂肪を燃焼する。
1のフェーズ等で筋肉をつけていればつけている程その効率が良くなります。

逆に悪い方法は何も食べないで体重を落とす方法です。
食べないことで脂肪は減りますが、同時に筋肉も減っていきます。

目標体重に達した時、減量前と同じ食事を摂るとどうなるか?
答えは筋肉が減り代謝が減っている分、太りやすくなります。
これがいわゆるリバウンドというやつです。


・食事制限方法


筋肉を落とさずに脂肪を燃やすには脂質と糖質をカットし、筋肉の形成に必要なタンパク質を十分に摂れば良いのです。
辛い日々ですが、鍛えた後であれば身体のキレが増し、健康的な身体付きになることでしょう。

具体的に期間中食べても良いとされる食べ物を挙げていくと、


  • 鶏肉(主にささみ、むね肉皮なし)
  • シーフードミックス
  • 魚(青魚は油が多いのでなるべくダメ)
  • 玉子の卵黄抜き
  • ノンオイルシーチキン
  • 葉っぱ系の野菜(根菜はダメ)
  • きのこ

調理する上でも油や砂糖の量に気をつけます。できれば使わない。
さすがに上記のものだけ食べてると飽きてくるので、ゼロカロリーほげほげの食品はOK。

また、どうしても食べたい場合は朝だけお米もOK。
納豆やとうふも朝だけならばOK。

食べる量は腹八分目を5〜6食。
プロテインは一食としていい。海外製などの甘い製品は注意。
寝る前に甘いプロテインは検討。朝起きて、お腹が空いているようであればOK。

この期間中も注意するのはお腹を空かせちゃいけないということ。
最近はツナ缶が携帯に便利な上に、低カロリー高タンパク食で良かったので愛用してます。


↑脂質がほとんど無いのに高タンパクで、野菜スープ調理されてるので他のノンオイルツナ缶より美味しくてオススメ

この脂質糖質抜き生活を3週間続けるように言われました。
もちろん、トレーニングは週2〜3回続けます。

・2のフェーズを10日間やってみて


69kgあった体重が65.9kgまで減っていました。さすがに痩せすぎです。
原因は食事量不足でした。
確かに脂肪はかなり減って、顔つきも変わるレベルです。

この期間の食事がとにかく難しい。
特に外出中は真面目に決まったものしか食べないという生活ができません。
人と合わせて飲みに行くのも難しく、人付き合いの多い人は大変だと思います。

あと決まったものを大量に食べるというのは精神衛生上良くはないですw
エサを食べている感覚になりますw

・打開策


無理に食事制限しようとすると、今度は筋肉も減ってしまい良いことがありません。
生活に合わないのであれば、少し縛りを緩くするのもモチベーション維持のために大切です。

今回の体重の推移から、トレーナーから2週間で食事制限打ち切りという話になりました。
身体のキレを出すのが目的だったので、思った以上のペースでそれを達成していたので問題はなかったようです。

残りの期間は朝+昼のお米・豆腐・豆類が解禁になりました。
夜の食事は現状維持です。
あとはトレーニング回数を増やすように言われています。


まとめ

トレーニングを続けながら太る勢いで飯を食って筋肉を大きくする

ある程度まで来たら脂質と糖質をカットした食事に切り替える

上記を各自の生活スタイルに合わせて縛りを変えて繰り返す。
(痩せたい人は脂質糖質カット+タンパク質摂取+トレーニングを続ける)


引き続き頑張ります!目指せモムチャン(人´∀`).☆.。.:*・゚

2013-10-09

grunt使ってstylusコンパイル>コピー>minify>結合>画像最適化までやる

Gruntめっちゃ便利ですね。
最近のお仕事でも使われていたので参考にしたり、これから個人でフロントエンドの実装するときも楽できるように自分用に作ってみました。


やりたいこと

今回css書くときにstylusを使ってみたかったのが始めた動機でもあるんですが、


  1. stylusをコンパイル
  2. tmpディレクトリに作業一時的にコピー(いらんかもw)
  3. minifiして結合したjsとcss、最適化した画像ファイルをappディレクトリにデプロイ

みたいなことをやろうとしてて、これを更にgruntでwatchして、更新が入る度に実行してやろうという魂胆です。
stylusのコンパイルが結構手間だと思うので、gruntでファイル監視することで開発が楽になりますね。

あと、minifyしたものを更に結合(conbine)しているのは、で呼び出すファイル数をjsとcssで1つに減らすことが出来て良いかなとおもったのでやっています。
簡単キレイなライブラリを色々入れなきゃいけない時は重宝するのではないでしょうか。(今回はjqueryと写真閲覧系ライブラリ2つを使ってみています。)

画像最適化はおまけです。

実践

ソースはこんな感じ



今回使っているgruntのnpm tasksは
  • grunt-contrib-watch → ファイル更新監視
  • grunt-contrib-stylus → stylusのコンパイル
  • grunt-contrib-copy → ファイルコピー
  • grunt-contrib-uglify → jsのminify
  • grunt-contrib-cssmin → cssのminify
  • grunt-img → 画像最適化
ですね。

grunt-contribだけで全部入りらしいんですが、軽量な状態にしてあったほうが良いかなと思ってこうしてます。

1. grunt-contrib-watch : ファイルの更新監視

  watch: {
   stylus: {
    files: [
     './src/css/**/*.styl'
    ],
    tasks: ['stylus']
   },
   reload: {
    files: [
     './src/**/*.html',
     './src/css/**/*.css',
     './src/js/**/*.js'
    ],
    tasks: ['reload']
   },
   reloadImg: {
    files: [
     './src/img/**/*'
    ],
    tasks: ['copy:img', 'img']
   }
  }

watchの中にstylusファイルの監視とその他html, css, jsファイルの監視、grunt-imgが遅いので別途分けた画像ファイルの監視がそれぞれ置いてあります。
この設定がある状態で、/srcディレクトリ以下の各ファイルどれかを編集すると、tasksの中身が実行されます。

2. grunt-contrib-stylus : stylusのコンパイル

   stylus: {
   compile: {
    src: './src/css/main.styl',
    dest: './src/css/main.css',
    options: {
     compress: false
    }
   }
  },
 

watch:stylusから呼ばれているタスクです。
自分で編集する.stylファイルをmain.stylだけにして、main.cssという名前で出力される用になります。
optionでcompressした状態のcssが出せるようになってたので使ってみたのですが、後ほど他cssと一緒にcssminするのでここでやるのはやめておきました。

ここでwatchをみると、このタスクで生成されたmain.cssに変更が加えられるのでreloadのタスクが走ります。便利ですねぇ。


3. grunt-contrib-copy : ファイルコピー

  copy: {
   img: {
    files: [{
     expand: true,
     src: '**/*',
     dest: './tmp/img',
     cwd: './src/img'
    }]
   },
 
   js: {
    files: [{
     expand: true,
     src: '**/*',
     dest: './tmp/js',
     cwd: './src/js'
    }]
   },
 
   css: {
    files: [{
     expand: true,
     src: '**/*.css',
     dest: './tmp/css',
     cwd: './src/css'
    }]
   }
  },

copyの中で使われています。
試しに使ってみただけなので使い方間違ってる感じがしますが、作業用・準備用・デプロイ用と分けてGruntfileを書いてみただけです。


4. grunt-contrib-uglify : jsのminify

  uglify: {
   dist: {
    options: {
     mangle: true,
     preserveComments: 'some'
    },
    files: [
     {
      './app/js/hoge.js': [
       './tmp/js/lib/jquery-2.0.3.js',
       './tmp/js/lib/jquery.flexslider.js',
       './tmp/js/lib/klass.min.js',
       './tmp/js/lib/code.photoswipe-3.0.5.js',
       './tmp/js/main.js'
      ]
     }
    ]
   }
  },

ここでは圧縮から結合まで一気にやっています。
結合されたファイルが、どこからがどのファイルなのか試すために、コメントを残すオプションなどが付いています。
便利ですねぇ。。


5. grunt-contrib-cssmin : cssのminify

  cssmin: {
   minify: {
    expand: true,
    cwd: './tmp/css',
    src: '**/*.css',
    dest: './tmp/css',
    ext: '.min.css'
   },
   conbine: {
    files: {
     './app/css/hoge.css': [
      './tmp/css/flexslider.min.css',
      './tmp/css/photoswipe.min.css',
      './tmp/css/main.min.css'
     ]
    }
   }
  },

uglifyのcss版です。
各種ライブラリで必要なcssが圧縮、結合されています。
圧縮したファイル名を".min.css"としたりできるのでやってみました。便利。


6. grunt-img : 画像の最適化

  img: {
   dist: {
    src: ['./tmp/**/*'],
    dest: './app/img'
   }
  },

やってみたかっただけです。
gruntはこんなことまで出来るんですねぇ。凄いっす。



使い方

上の方に
 grunt.registerTask('default', ['stylus', 'copy', 'uglify', 'cssmin', 'img']);
 grunt.registerTask('reload', ['copy', 'uglify', 'cssmin']);
 grunt.registerTask('dev', ['watch']);
が用意されています。

defaultがただgruntと実行した時の全部入りタスク。
reloadはwatch:reloadから呼ばれているタスク。
dev(名前変えるほどのこと無かったな。。)はwatchが始まるだけのタスクです。今後なんかクライアントサイドのtestとかjsHint足すかも。

まぁこんなもんか。


まとめ

stylusの自動コンパイルがしたかっただけなのに壮大なGruntfileになってしまった。
実際使ってみると、uglifyが結構無茶してたりするのでちょっぴり遅い。

最終的にデプロイするときは問題無いと思うんだけど、開発中はちょっと大げさなので、src内で完結する様な構成も今後は考えたいですね。

特にminifyしてるからjsのデバッグが大変そう。
deployタスクみたいなlocalと本番で別にタスクを用意したりしなきゃなぁと思いますた。