Twitter Facebook github

Category “開発環境”

モダンなフロントエンド開発環境をつくる

最近、趣味で作りたいWebアプリがあって、結構クライアント側が要になりそうなので、思い切って勢いで Deep Dive してみた話。かなり長いです。

モダンって言ってるけど、TypeScriptが苦手ならES2015+ES7も全然アリだと思う。前回の記事で触れてるから、TypeScriptの代わりに書き換えればうまく載るはず。というか人口的にはTypeScriptよりES2015使う人のが当然多いだろうけど、今回はTypeScript使ってみたかったんです・・・。

背景

わたしは今までフロンドエンド開発っていうと、CSS3+HTML5で特別な開発環境も使わず、気合いで頑張って作ってきた勢です。

一応、フリーランスでバックもフロントもまとめて依頼されたり、趣味で書いたり、プログラミングスクールで先生やってた頃はフロントも教えていたんですが、とても苦手でした。特にデザインとか全くセンス無いし、デザインも決まってないようなサイトをまるっと任されたりするとすごくストレスで辛かったのを覚えています。

最近はバックエンドやインフラにフォーカスした仕事をしていて、ほぼほぼフロントを書くこともなくなったのですが、数年前より便利なツールや面白そうなライブラリがいろいろ増えていて、せっかく書くならとことんモダンに!ということでやってみました。

今回のゴール

ここで作る環境の最終的なコードはgithubにあります。
https://github.com/syamn/sakuio-blog-160314

  • node.js と npm をインストール
  • JavaScript には TypeScript を使う
  • CSS には Scss (Sass) を使う
  • ビューライブラリには RectJS を使う
  • WebPackだけでビルド (GruntやGulpは使わない)
  • WebPack-Dev-Serverで自動リフレッシュを試してみる

ネットで情報を探すと、TypeScriptやScssのトランスパイルには未だにGulpが主流で(Gruntは減ってきましたね)、せっかくWebPackを導入してもGulpと組み合わせて使うみたいな記事を多く見かけます。

せっかくWebPackを導入したのなら、WebPackだけで完結させましょう〜!

Read More »

WebPackでES6とES7をトランスパイルする

最近趣味の開発範疇でフロント側の勉強をしています。
ビルドツールにWebPackを採用したのですが、ちょっとハマったことがあったので備忘録です。

やりたいこと

  • JSもCSSも画像もオールインワンに使えるWebPackを使ってビルドしたい
  • フロント側のJSもES6とES7の構文を取り入れて書きたい

Read More »

SixのエラーでAWS CLIをMacにインストールできない

めっちゃハマったのでメモ。環境は Mac El Capitan (10.11.3) 。

周りの人はすんなりインストールできてたりするので、どうしてこうなったのか原因が分からないのだが、うまく抜け出せたので書き留めておきたい。

AWS CLIをMacにインストールしようとした

Macなら初めからpythonが入ってるから2コマンドでいける……らしい。

普通ならこれだけでインストールできる。

1行目でpythonパッケージマネージャーのpipを入れて、2行目でawscliをインストール。

これがエラーなく完了すればいいけど、手元の環境ではなぜか2行目でコケてしまった。

Operation not permitted

こうなった。

よく見るとDeprecatedなSixっていうパッケージをアンインストールしようとしてエラーになってるぽくて、
手動で sudo pip uninstall six ってやっても同じエラーが出てしまう。

解決策

うまくいった!

ちなみにSixっていうのはpython2系と3系の差異を埋めてくれるユーティリティライブラリみたいなものらしい。やっぱり自分で入れた覚えはなくてちょっと謎。

はじめてのgit

gitについて話すときにこの記事をたたき台にしたい。はじめてgitに触れる人の理解の助けになれば。

個別のgitコマンドについては、「頻出gitコマンド入門」で紹介しているのでリファレンス的に使ってください。ここでで紹介しているコマンドに関してはさらっと流して、できるだけシンプルに。

Read More »

頻出gitコマンド入門

最近、gitの使い方を人に説明することが多くなってきたので、頻出コマンドの使い方をリファレンス的に纏めておこうと思います。

なお、対象読者はgithubを用いてチーム開発をしているプログラマーです。
一人で開発するのであれば、例えばリモートサーバーへのpushやpullなどは無視してよいでしょう。

応用的なコマンドは分量を考えてまた別の記事にするかもしれません。適当にアップデートしていきます。

Read More »

VagrantのゲストOSから名前解決できない件

昔の記事「Vagrant+Chef-Zero入門」でprovisionを行おうと思い、vagrant upしたところ、次のエラーでプロビジョニングがコケました。

よく見るとinline scriptとchef両方でコケてる

inline script はゲストOSにchefをインストールするスクリプトで、opscode.comからダウンロードしてくるのですが、3行目でこれが失敗しています。
原因はホストアドレスの名前解決ができなかったようですね。

chefがインストールできていないので、chef provisionがコケるのは当然なのですが、14行目でも network is unreachable ということで、ゲストOSから名前解決が正しくできていないために、インターネットに出て行けなかったのではないかと推測できます。

解決策

ゲストOSから名前解決がうまくいかないとき、ホストOSで名前解決するようプロキシする設定にすることが可能なようで、VirtualBoxの NAT Networking settings に詳細が記載されていました。

https://www.virtualbox.org/manual/ch08.html#idp46608649138592

今回はこの設定の中の natdnshostresolver をVagrantfileから有効にします。

vagrant up でVMを立ち上げ直すと、正しく名前解決が行われるようになります。

このオプションを有効化することによる副作用はなさそうなので、配布する場合は付けておいたほうがよさそうです。

所感

この原因が解明できておらず曖昧なのですが、Vagrantを使っているとネットワーク周りの問題にはよく遭遇します。
自分の中でネットワークに関しては知識面において弱点でもあるので、克服できるように精進したいと思います。

余談ではありますが、本記事内や以前の記事で書いた opscode.com は chef.io に引っ越しが行われており、古いドメインでもリダイレクトされますが、DNSルックアップが2度走ることになるので気になる方は新しい方を参照するように修正すると良いでしょう。

git-secretsでAWSの不正利用を防ぐ

最近、アプリケーションなどから利用するAWSの認証情報(credentials)をgithubなどの公開リポジトリに誤ってコミットしてしまい、不正利用され高額な使用料を請求されるケースが増えています。
いくらルートアカウントを無効化してIAMユーザーを使おうが、2段階認証を導入しようが、認証情報をヒューマンミスで公開してしまっては意味がありません。

万が一、認証情報を公開してしまった場合は、一刻も早くAWSの管理コンソールから公開してしまった認証情報のアクセス権限を取り消しましょう。もしそれが会社で使っている認証情報だとしたら本当に1分1秒を争いますので、深夜だろうが構わずにAWSを管理しているエンジニアを電話で叩き起こして助けを求めてください。放置すると高確率で首が飛びます。

こういった大事故を防ぐためにAWSが公開している git-secrets というgitのプラグインがあります。

https://github.com/awslabs/git-secrets

インストールする

つい先月末までは、インストールするためにソースをローカルにクローンしてきた後で make install する必要がありました。しかし、先月の26日にformulaがHomebrewのmasterにマージされ、brew経由でより簡単にインストールできるようになりました。

昔からhomebrewを使っていた人は、formulaの一覧を更新しないとインストールできないため、まずupdateしてからinstallします。

git secrets コマンドが使えるようになっているはずです。

リポジトリへ設定

git-secretsはまだ有効になっていません。

リポジトリ単位で有効化する必要があるので、ここでは適当に新しいリポジトリを作ることにします。

リポジトリの中にcdしたら –install で有効化。

見ての通り、pre-commitをフックして実現しています。

拒否ルールの設定

次にどのルールにマッチしたとき、コミットを拒否するか指定します。AWSの認証情報については、 --register-aws パラメータを使えます。

設定された拒否ルールは、 --list パラメータで確認できます。

上の出力3行目では、大文字英数20文字にマッチして拒否しているようですね。乱暴じゃないかと思いましたが、実際プログラミングをしていて大文字固定で20文字も打ちませんからね。

6,7行目はAWSの公式ドキュメントなどでも使われている、サンプルのアクセスキー/シークレットキー(Allowed patterns for example AWS keys)だそうです。

実際に使ってみる

ちゃんと弾いてくれるか確認してみます。

適当にそれっぽいのを書いて、これでコミット。

弾いてくれました!

まとめ

実際の運用では、認証情報やパスワードなど本当に外部に漏れてマズいものは、環境変数にセットするのが個人的にはオススメです。そもそもファイルに書かない運用であれば、ファイルの取扱い不備でリークする可能性がゼロになり、セキュリティリスクを減らせます。

とはいえ、実情そんなこと言ってられないケースも多いですので、ファイル+.gitignoreで気をつけて運用するのが一般的でしょうか…。万が一のためにAWS内外問わず、トークンごとに権限設定ができるものは必要最小限の付与に留めるようにしましょう。AWSの場合、ルートキーでないと使えないAPIがあったりもするみたいですが……。

今回のgit secretsは他にも、既にインデックスされているファイルの中にキーが混ざっていないかどうかをスキャンしたりすることもできます。詳しく知りたい方は公式のドキュメントをどうぞ。

所感

AWSなんかは凄い勢いで請求額が増えていくサービスが山ほどあります。ルートキーなんかが漏洩したと思うとゾッとしますね……。従量課金制のクラウドサービスを使う際には、そのセキュリティにはより一層の注意を払って取り扱いたいですね。

バグを減らすためにユニットテストを考える

ユニットテスト基礎

前提として

  • 「バグがある」ことを証明できるが、「バグがない」ことは証明できない
  • バグを限りなくゼロに減らすために有限時間内でチェックを行っている
  • ステートが増える毎にテストケースとテスト時間は指数関数的に増加する
  • ウェブサービスでブラウザを介して行うものは完全なブラックボックステストであるし、仮に誤った出力となるケースを発見しても、そのリクエスト内のどの段階(メソッド)でバグが起きているのか特定することはできない

基礎知識

テストは最低限の品質保証です。

テストを行っていなかったプロジェクトにテストを導入する場合、「この関数の結果は最低限、保証されていなければならない」とする関数を最優先のテスト対象とします。
ただし、テストを実施するためには、テストを行いやすい設計が必要不可欠であるため、既存のコードのままテストを実施しようとは考えない方が良いでしょう。

また、ユニットテストは、リグレッションテスト(デグレードテスト)を行うための最適な方法です。リグレッション(デグレード)というのは、新たに機能を追加したり、既存のコードのバグを修正した際に、新たなバグを生みだしてしまうことです。ユニットテストを正しく行っていれば、常に要求を満たすテストケースによって過去の修正内容も検証され続けることになるためです。

またテストコードを書く習慣のない人が書いたコードは総じてテストしにくいコードを書く傾向にあり、テスト導入を決めたプロジェクトでテストコードに関する知識の無い人にコードを書かせ続けるのはとても非効率です。…それでも、テストコードを書く人が指摘しないといつまでも書けるようにはなりません。

テストコードは誰でも書けるのか

正しいテストコードを書くにはプログラミングの知識だけでなく、テスト工程におけるテストスキルと経験も必須です。

機械的に行うユニットテストなどのソフトウェアテストは、ブラウザを介した出力を人間が目視で行うブラックボックステストと根本的に異なります。たとえば今回取り上げているのはユニットテストですが、その具体的なテストケースには同値分析や境界線分析など多くの手法があり、また適切なテストケースを書くことができないのであれば、テストコードを書かないも同然です。

なにより、実施しようとしているテストの基礎知識がなければ、どの程度テストコード、テストケース、カバレッジを維持すれば十分という判断をすることができないし、そもそもプログラミングの知識がなければテストコードを書くことも出来なければ、テスト対象のコードを読んで適切なテストケースを作ることも不可能です。

ゆえに、テストコードを書くにはテスト対象のコード(つまりビジネスロジック)を書く以上のスキルと経験が必要と言えます。

テストコードを書かないのは悪ではない

ユニットテストはソフトウェアテスト手法の一つですが、これは通常の開発手法(例えばウォーターフォールやアジャイル、スクラム等々)と同様に、適用して効果的なプロジェクトもあれば、むしろ適用した結果マイナスに作用してしまうプロジェクトもあり、すべてのプロジェクトに導入を勧められるものではないことを理解してください。

そのため、事前にユニットテストを導入するのが本当に効果的なのかどうかを検討・判断する必要があります。

ユニットテストが効果的なプロジェクトの条件を次に挙げます。

頻繁にリリースが行われる

例えばリリースが年に数回のように、頻繁にリリースをしない場合、手動テストのコストが相対的に小さくなり、ユニットテストを導入するコストの方が大きくなります。逆にアジャイルで毎日デプロイを繰り返すようなプロジェクトの場合、手動テストだけでは太刀打ちできなくなることでしょう。

長い期間保守される

リリース頻度と同じ考え方ですが、短時間で保守されなくなるプロジェクトでは、トータル的に自動テストが実行される回数が少なくなるため導入コストの方が大きくなります。例えばサービス案を練って試作してみる時のプロトタイプなどに導入するのは不向きということになります。

多くの人数が開発に関わる

例えば1人で開発を継続できる規模のプロジェクトでは、当人がすべてのコード・仕様を把握しているケースが多く、テストコードを導入したとしても成果物の品質に影響を与えないことが多いです。逆に数十人規模の開発チームの場合、一人がすべてのコードを把握するのは不可能でしょうし、初めて触れるコンポーネントの改修を安心して行うことができるようになります。

ただし、頻繁に参加しているメンバーが変動するプロジェクトの場合、テストコードのメンテナンスコストが高まり、テスト自体が破綻することがあるので注意が必要です。

また、ある程度コードの規模が大きくなってきたプロジェクトにおいては、トータルで見たとき「自動テストを導入した後の開発速度」の方が導入前と比べて早いことも多いのですが、その段階以前の小規模なプロジェクトでは、自動テストを導入しない方が開発速度は速くなります。実際のビジネスの世界では品質よりスピードを重視することも多々あるので、開発ステージに応じた選択が必要になります。

「テスト駆動開発」のススメ

テスト駆動開発とは

一般的な開発工程では、機能実装者=その機能のテストコード実装者になります。

ユニットテストは学校のテストに例えると、

  • テストコード=問題(先生が出題する)
  • ビジネスロジック(機能)=解答(生徒が解く)

なので、

  • 「先に答え(機能)を書いてから、問題を出題(テストコードを実装)する」

より、

  • 「先に問題(テストコード)を書いてから、その問題に答える(機能を実装する)」

方が考え方としてはより適切であり、成果物の品質向上を期待できます。

このように、先にテストコードを書いてからビジネスロジックを実装する開発手法をテスト駆動開発(テストファースト)と言います。

テスト駆動開発には、テスト対象のコードを書く前の時点でその全体像を頭の中で設計する必要があり、プログラム初学者が習得するのは困難です。

テスト駆動開発 は開発が遅くなる?

テスト駆動開発を実施すると生産性が下がると主張する人も多いのですが、実際は正しくテストが行えていればトータルで見た生産性は上がります。

何故かというと、実際にコードを書くエンジニアでないと分からない感覚かもしれませんが、エンジニアが「実際にコードを書く時間」より、「処理を頭の中で考えて設計する時間」と、「書いた後の動作チェックの時間」の方が長くなりがちです(そうでないケースを私は知りません)。

特に新人の頃は設計も未熟であり、十分に頭の中でシュミレーションできず、いきなり手を動かしてコードを書く作業に入るために無駄なコードが増えがちです。
しかしその繰り返しによって知見が十分に溜まることにより、手を動かす前に今から書こうとするプログラムの全体像を自然とイメージできるようになります。
経験を積み重ねた熟練者はコードの実行結果を頭の中でシュミレーションできるので、無駄なプログラミングを初めからしなくなります。

従って、テスト駆動開発の導入によりテストコードを先に書くことによって、開発工程で一番時間のかかる「脳内設計工程」と「動作チェック工程」が一体化し生産性が向上します。

結論

何が言いたいのか分からなくなってきました。ここまで書くのに疲れました。また考えておきます。

所感

ここまで語れるほどユニットテストの経験が長いわけではない…はずが、いつの間にか書けるくらいの知識量になっていました。初学者だった頃は「テスト難しそう…書くと遅くなるし要らないや」なんてよく思っていました。懐かしいです。

デプロイ用ユーザーの在り方を考える

たいそうなタイトルだけど実際そんなことない。思ったより長くなってしまったのでお時間のあるときにどうぞ。

 

今までWordPressのデプロイにはrsyncを使って同期させていたんですが、WordPress専用のRuby製デプロイツール、WordMoveを使ってみようと思い立ちこちらの記事を参考にしながら準備しました。

WordMoveはSSHやFTPでログインしてファイルを置き換えるために、ログインユーザーがドキュメントルート以下への書き込み権限を持っていないとデプロイできません。

前述の参考記事ではドキュメントルート以下の所有者と、ウェブサーバーの実行ユーザーをec2-userに変更する荒技で解決しています。ここが自分の中でめちゃくちゃ引っかかったので、セキュリティ的により良いと考える権限管理ついて書いてみます。

(後から調べたことですが、Red Hatが共有ディレクトリのベストプラクティスとして提案していたようです。)

 

今回のゴール

  • デプロイ用の専用ユーザーを作り、WordMoveはデプロイ用のユーザーからデプロイを実施する
  • ウェブサーバーの実行ユーザーは変更しない(apacheまたはnginx)
  • 上記のままうまく回るようにユーザーとディレクトリのパーミッションを変更する

 

デプロイ元の環境で鍵ペアを作る

今回はVCCWを使ったVagrant内のWordMoveを使います。特にWordMoveはrootになって使う必要もないので、今回はvagrantユーザーで鍵を作ります。

秘密鍵のパスフレーズは必要に応じて設定してください。

ssh-keygenコマンドで鍵ペアが生成されますが、触れていいのは ~/.ssh/id_rsa.pub のように最後にpubが付いたものだけです。これがWordMoveの公開鍵になるので控えておきます。なお、当然ですが ~/.ssh/id_rsa は秘密鍵です。これを漏らしてしまうとデプロイ対象のドキュメントルート以下を丸々書き換えることができてしまうので、十分に気をつけてください。

 

デプロイ用のユーザーを準備する

ここでは deployer という名前で作成します。

 

デプロイユーザーが対象のディレクトリに書き込めるようにする

今回のデプロイ対象はウェブサーバーの実行ユーザーが所有しているドキュメントルートです。

今回はnginxを使っており、所有権はnginx:nginxです。戦略としては、nginxのグループにdeployerユーザーを追加し、ドキュメントルート以下のディレクトリに対してグループ内からの書き込み権限を付与します。

 

これで終わり…なら簡単で、記事にすることもないんですが、2つ問題があります。

deployerでファイルの編集をしてみます。問題なくできます。

 

次はデプロイ先にないファイルをデプロイしてファイルを作成することを想定してtouchしてみます。

次にパーミッションをチェックします。

1つめの問題です。このように、新規でファイルを作成してしまうと所有権は deployer:deployer になってしまいます。deployerグループにnginxを追加してしまう方法もありますが、一貫性が無くなってしまう上に、何かグループに対して権限を付与する際にも複数のグループを気にすることとなり運用コストが高まります。

これを解決する方法として特殊なパーミッションビット、setgidを使います。

 

setgidを理解する

setgidというのは、setuid, setgid, sticky bit と並んで紹介されることの多いLinux系ファイルシステムにおける特殊なパーミッションビットのことです。今回はsetuidとsticky bitは使わないので省略します。

setgidはset group idの略で、このパーミッションを有効にしたディレクトリ内でファイルやサブディレクトリを作成すると、setgidを付与したディレクトリと同じグループが所有グループとなります。グループを継承することができるということです。

setgidはchmodコマンドで g+s を指定することで設定できます。

チェックしてみます。

デフォルトでグループがnginxに割り当てられています。

今度こそ終わり… と思ったら、新しく作られたファイルのグループはnginxになっていますが、よく見るとグループへの書き込み権限がありません。2つめの問題です。

 

デフォルトパーミッションを変更する

ここまでで、ファイルやディレクトリを作成したときに所有グループを継承できるようになりました。最後は、デフォルトのパーミッションでグループに書き込み権限を付与することです。これにはumaskを使います。

umaskは許可*しない*ビットを指定する方法なのでかなり柔軟に設定できます。デフォルトではumask 022(=新規ファイルは644、自分だけ書き込み可)になっていますので、今回はumask 002(=664、自分とグループの人が書き込み可)に変更したいわけです。

今回はdeployerユーザーにumask 002を付与したいので、deployerユーザーの .bash_profile を利用します。

テストしてみます。ただし、sudo -u deployerを使うとrootのログインシェルに入ってしまいumask 022が適用されてしまいますので、su – を使います。

新規ファイルも664のパーミッションで、グループを継承できました!念のためにサブディレクトリを作って、その中でファイルを作っても同様の結果になることを確認しておきましょう。テストが済んだらテスト用ファイルはすべて消しておきます。

 

WordMoveでデプロイしてみる

今回はWordMoveを使っていますがWordMoveの紹介ではないので簡単に。実際にdeployerユーザーを使ってデプロイしてみます。

Pulling Databaseで、サーバー側でmysqldumpが効かなくて一度コケましたがmysqlをyumで入れて解決しました。

ちゃんとプッシュできていることを確認して終わりです。お疲れ様でした。

 

雑感

ここまで書いておいて何ですが、本当はこのように役割ごとにユーザーを切り分けるべきだと信じています。ただめちゃくちゃ面倒くさくて、最後デプロイツールでも一工夫必要なことを考えると、同一ユーザーでやってしまいたくなるのもとても分かります。難しいですね。

Vagrant+Chef-Zero入門

今更感があってごめんなさい。確かにAnsibleとかFabricとか流行ってますもんね。でも老舗感と重厚感あるChef触っておくのもいいと思うんです。にしてもChefって色々複雑そうで入りにくいですよね…。

私はChef初級者です。一応裏付けは取るようにしていますが、もし間違いがあれば指摘いただけると嬉しいです。

Chef-Zeroっていうのは、消えゆく(らしい)Chef-Soloに代わる形で推奨されている単体で動く環境構築の自動化ツールです。元々Chefはサーバーとクライアントが分かれているアプリケーションですが、Chef-Soloは独立して動くChefで、Chef-Zeroは1つのマシンにサーバーとクライアントの両方を入れたようなイメージらしいです。

 

導入編

昔はRubyのgemでChef入れて、関連ツール入れて・・・のような形でRubyの環境がない人はそこから、という結構導入が重めでした。

最近はChefDKというのがあり、Chef本体とその関連ツールを一気にインストールできるようになっています(実際は内部でgemが使われているんですが…)。

https://downloads.chef.io/chef-dk

今回はこのMac用のChefDK、執筆時点の最新 0.10.11を使います。バージョン番号から察するに、まだ正式リリースではないようですがインストールされるChefは最新のものなので心配ありません。

インストール直後のバージョン情報は次の通りです。

 

Vagrantを準備

とりあえず適当にVagrantのゲストOSを用意します。今回は Vagrantことはじめ でダウンロードしてきた bento/centos-6.7 を使います。読むのに慣れてVagrantfileのコメントが邪魔になってきたら init時に –minimal (-m)オプションを付けましょう。コメントが消えてくれます。

Chefを使ってプロビジョニングを行うためには、ゲストOS内にもChefが必要です。色々な解説サイトを読むと、Vagrantのプラグインを入れてゲストOSにChefをインストールするような記事が多く見られますが、そうするとVagrantfileを配布する際にそのプラグインのインストール手順を共同開発者に伝え、手動で入れてもらう必要があります。せっかくの自動化なのに、vagrant upだけで完結させたいですよね。なので今回はChefのインストール部分だけインラインシェルを使うことにします。

 

Chefリポジトリを作る

まずはベースとなるリポジトリを作ります。今後はこの中で作業するので、移動しておいてください。

 

Cookbookを作る

オリジナルなcookbookはデフォルトで作られているcookbooksではなくsite-cookbooksに入れるのが慣習のようなので、それに従おうと思います。ここでは例として空のCookbookを置いてみます。

これで空のクックブックができました。

 

Berksfileを作る

実際にCookbookの中身を作り込む前に、Berkshelfへの登録を済ませておきましょう。
BerkshelfというのはRubyのBundler、PHPのComposerのように、Cookbookに依存するCookbookを自動で入れてくれるCookbookマネージャーのような役割を担います。

Berkshelfで自分の使いたいCookbookを記述しておくのがBerksfileになります。これをChefリポジトリのルートに作ります。

1行目のsourceというのは、指定された名前のCookbookをデフォルトでどこから落としてくるか指定します。今回は有名な Chef Supermarket を使いました。

その後で使いたいcookbookの名前とバージョンを指定し、

コマンドを実行することで、 Berksfileを元にcookbooksディレクトリに依存性が解決されたCookbookが保存されるようになります。

実際に上のコマンドを実行してみてください。./site-cookbooks/do-something が ./cookbooks/do-something にコピーされたと思います。今回のようにpathパラメーターにローカルのCookbookを与えた場合は、sourceに記述したリモートロケーションではなく指定されたローカルのCookbookを見に行くようになります。

 

Vagrantのプロビジョンで実行する

Chef-Soloでプロビジョンを行ったことがある人は同じように使えます。

chef_zero provisionerを使って、cookbooksのディレクトリと実行するレシピをadd_recipeで列挙していきます。

add_recipe の代わりに add_role を使ってRolesという機能も使えます。これは複数のレシピをロールという単位で管理することで、役割という意味単位でグルーピングして扱うことができます。

 

Marketで公開されているCookbookを使ってみる

既に作った do-something のCookbookを自分で書いてもいいのですが、とても長くなってしまうので今は公開されているCookbookを使ってみます。例えばApacheやMySQL Serverなどの有名どころは大抵公開されているので、そもそも自分で一から書くことは少ないかもしれません。

上でBerksfileのsourceに指定したURLが Chef Supermarket です。

https://supermarket.chef.io/

今回はApacheのCookbook、 apache2 を使ってみようと思います。

berks vendorでCookbookを取得してきます。

cookbooksディレクトリの中にapache2のcookbookがインストールされればOKです。

Vagrantfileにも追加して、実行してみましょう。

プロビジョンが完了したら、正しくインストールされているか確認してみましょう。

 

Vagrantfileを公開するとき

チーム内で開発用仮想マシンを共有したいときは、Vagrantfileの他に最低限 ./provision/cookbooksを共有するといいでしょう。Berkshelfがインストールされているユーザーであれば、 Vagrantfile+Berkshelfでなんとかなりますが、一般的にはVagrantfile+cookbooksの共有が多いような気がします。

 

まとめ

Chef勉強しながら作業内容の備忘録と共有のために書きました。実際これだけではChefの2割にも満たないくらいの知識量だと思います。学習コストが比較的高いですが頑張っていきましょう。