読者です 読者をやめる 読者になる 読者になる

まちいろエンジニアブログ

南池袋のWebサービス開発会社、株式会社まちいろのエンジニアブログです。

GitBook で作成したドキュメントを GitHub Pages で公開する

GitHub GitBook

f:id:mkudo-machiiro:20160915102741p:plain:w400

こんにちは、まちいろの工藤 (@macococo) です。

以前本ブログにて『まちいろブートキャンプの取り組みについて』という社内研修の紹介記事を書きましたが、
最近そのブートキャンプ用の資料を GitBook で作成して GitHub Pages で公開してみたので、今回はその手順を紹介したいと思います。

GitBook とは?

www.gitbook.com

GitBook とは、Markdown で記述したドキュメントを HTML や PDF に変換することができるツールです。

HTML に変換できるため、HTML をホスティングすることができる GitHub Pages と組み合わせることで、Pull Request フローを通して文章作成をしつつ、ドキュメントを公開することが可能です。

GitBook 用のリポジトリを作成する

まずは GitHub に GitBook 用のリポジトリを作成し、ローカルに clone しておきます。 ここでは gitbook-sample という名称にしました。

$ git clone git@github.com:mkudo-machiiro/gitbook-sample.git

次に gitbook-cli をインストールします。

$ cd gitbook-sample
$ npm init
$ npm install gitbook-cli --save

gitbook コマンドが実行できるよう、package.json の scripts を編集します。

{
  "scripts": {
    "gitbook": "gitbook"
  }
}

gitbook init コマンドでリポジトリを初期化します。 成功すると、目次にあたる SUMMARY.md と、コンテンツに当たる README.md が自動で作成されます。

$ npm run gitbook init
> gitbook-sample@1.0.0 gitbook /Users/mkudo/dev/sandbox/gitbook-sample
> gitbook "init"

warn: no summary file in this book
info: create README.md
info: create SUMMARY.md
info: initialization is finished

gitbook serve を実行すると、Web サーバーが起動します。

$ npm run gitbook serve

> gitbook-sample@1.0.0 gitbook /Users/mkudo/dev/sandbox/gitbook-sample
> gitbook "serve"

Live reload server started on port: 35729
Press CTRL+C to quit ...

info: 7 plugins are installed
info: loading plugin "livereload"... OK
info: loading plugin "highlight"... OK
info: loading plugin "search"... OK
info: loading plugin "lunr"... OK
info: loading plugin "sharing"... OK
info: loading plugin "fontsettings"... OK
info: loading plugin "theme-default"... OK
info: found 1 pages
info: found 1 asset files
info: >> generation finished with success in 0.7s !

Starting server ...
Serving book on http://localhost:4000

ブラウザから http://localhost:4000 にアクセスすると、ドキュメントが閲覧できます。

f:id:mkudo-machiiro:20160915094247p:plain

GitBook からドキュメントの HTML を出力する

gitbook build を実行すると、Markdown から HTML を生成することが出来ます。

第1引数には、Markdown が配置されているディレクトリを指定します。
現在の GitHub Pages は docs/ 配下にある HTML をホスティング可能なため、 docs/ 配下に出力するように第2引数にを指定します。

$ npm run gitbook build ./ docs/ 

無事出力されたら GitHub に push しておきます。

GitHub Pages を有効にする

GitHub の [Settings]-[Options]-[GitHub Pages] ページにアクセスし、Source に master branch /docs folder を選択して【Save】ボタンをクリックします。

f:id:mkudo-machiiro:20160915101355p:plain

画面がリロードされ、GitHub Pages の URL が表示されれば成功です。アクセスすると GitBook のドキュメントが表示されます。

f:id:mkudo-machiiro:20160915101611p:plain

まとめ

GitBook + GitHub Pages で、Markdown ドキュメントを簡単に公開することができました。

肝心のブートキャンプ用資料ですが・・・まだ書き途中です。 が、お試しで公開してみています。

bootcamp-javascript

今後も公開できるものは少しずつ GitBook で書いていこうと思います。

SSLサーバー証明書を更新する手順

SSL

こんにちは、まちいろの井上です。

まちいろでは様々なお客様のサイトを管理しており、日々の運用の中でSSLサーバー証明書の更新作業を行うことがあります。

つい最近も、お客様のサイトのSSLサーバー証明書の更新を行いました。

そこで今日は、XAMPP for Linux 環境でのSSLサーバー証明書の更新手順についてご紹介したいと思います。

SSLサーバー証明書発行の事前準備>CSRの発行

SSLサーバー証明書を発行する前に、CSRの発行が必要となります。

CSRとは、SSLサーバー証明書を発行するための署名要求(Certificate Signing Request)と呼ばれるもので、このCSRを元に認証機関により SSLサーバー証明書の発行が行われます。

それでは、まずはじめにCSR発行の手順についてご紹介します。

Opensslインストール確認

サーバーにSSH接続を行い、サーバーにOpensslがインストールされていることを確認します。

$ openssl version

秘密鍵を生成する

秘密鍵の作成を行うフォルダに移動後、秘密鍵を生成します。

秘密鍵の生成にはgenrsaコマンドを使用します。

$ openssl genrsa -des3 -out ./ssl.key/[秘密鍵名].key 2048

この時、2回パスフレーズを聞かれるので必ず覚えておきましょう。

作成した秘密鍵をもとにCSRを発行する

$ openssl req -new -key ./ssl.key/[秘密鍵名].key -out ./ssl.csr/[CSRファイル名].csr

このコマンドを実行すると下記項目の入力を求められますので、前回CSR発行した際の内容を設定していきます。

項目 説明
Country Name ISO規格の国コード JP
State or Province Name 組織が置かれている都道府県 Tokyo
Locality Name 組織が置かれている市区町村 Toshima-ku
Organization Name 組織の名称 Machiiro.inc
Organization Unit Name 組織での部署名 -
Common Name ウェブサーバのFQDN machiiro.co.jp
Email Address メールアドレス 入力不要
A challenge password パスワード 入力不要
An optional company name 組織名(補助) 入力不要

「Email Address」以降は設定不要なので、何も入力せずEnterを押してください。

万が一、前回の設定内容を忘れてしまった!という方は、下記サイトをご覧ください。

前回のCSR情報を入力することで、設定内容を確認することができます。

https://sstool.cybertrust.ne.jp/support_tool/index02.php

発行したCSRファイルをもとに、SSLサーバー証明書の発行を依頼する

SSL発行会社に依頼して、発行したCSRをもとにSSLサーバー証明書(crtファイル)、中間ファイル(cerファイル)を発行してもらいます。

SSLサーバー証明書の更新

発行されたSSLサーバー証明書(crtファイル)・中間ファイル(cerファイル)を受け取ったら、続いてSSLサーバー証明書SSL設定ファイルの更新を行っていきます。

SSLサーバー証明書をサーバーに配置する

発行されたSSLサーバー証明書(crtファイル)・中間ファイル(cerファイル)をサーバーに配置します。

今回は、例として下記のようなフォルダ構成で行います。

ファイル種別保存先フォルダファイル名
秘密鍵/opt/lampp/etc/ssl.keysample.key
SSLサーバー証明書/opt/lampp/etc/ssl.crtssl.sample.crt
中間ファイル/opt/lampp/etc/ssl.crtssl.sample.cer
SSL設定ファイル/opt/lampp/etc/ssl.confssl.conf

SSL設定ファイルを修正する

SSL設定ファイルのバックアップを取得後、下記のように設定ファイルの設定値を書き換えます。

項目 設定値
SSLCertificateFile /opt/lampp/etc/ssl.crt/ssl.sample.crt
SSLCertificateKeyFile /opt/lampp/etc/ssl.key/sample.key
SSLCertificateChainFile /opt/lampp/etc/ssl.crt/ssl.sample.cer

※必ずバックアップを取得してから、SSL設定ファイルの修正を行ってください。

※1台のサーバーで複数ドメインの利用をしている場合は、設定ファイルの中でそれぞれのドメインごとの設定があるので、変更漏れが無いように注意しましょう。

Apacheの再起動を行う

以下のコマンドを実行し、Apacheの再起動を行います。

$ /opt/lampp/lampp stopapache
$ /opt/lampp/lampp startapache

パスフレーズの入力なしでApacheを起動する場合は、下記のパスフレーズの解除を行った後にApacheを再起動してください。

  • keyファイルのパスフレーズを解除する(事前に必ず、keyファイルのバックアップを取得しておいてください。)

    $ openssl rsa -in [秘密鍵名].key -out [秘密鍵名].key

  • Apacheを再起動する

    $ /opt/lampp/lampp stopapache

    $ /opt/lampp/lampp startapache

まとめ

以上で、SSLサーバー証明書の更新作業は完了です。

SSLサーバー証明書には有効期限がありますので、早めに更新の準備を行いましょう。

AWS Lambda で EC2 インスタンスを自動起動・停止してみる (実装編)

AWS Lambda Node.js

こんにちは、まちいろの工藤です。

今回は前回の続きとして、AWS Lambda を用いてEC2 インスタンス自動起動・停止の実装に入って行きたいと思います。

仕様決め

まずは、今回実装する仕組みの仕様を決めたいと思います。

EC2 に OperatingSchedule という名称のタグを設け、起動時間-停止時間 (曜日)のフォーマットで設定可能とします。
この時間帯・曜日以外であれば自動的に停止するようにしたいと思います。

まちいろの就業時間である9時〜18時に稼働させたい場合の設定は以下のようになります。
起動はちょっと早めにしておきます。

f:id:mkudo-machiiro:20160615152325p:plain:w400

aws-sdk を用いて実装

Node.js で AWSAPI を実行するためのモジュール aws-sdk と、lodashmoment をインストールします。

$ npm install aws-sdk lodash moment --save

まず、OperatingSchedule タグを持つ EC2 インスタンスの情報を取得する必要があります。
aws-cliec2 describe-instances に相当する AWS.EC2.describeInstances メソッドを使用します。

  const ec2 = new AWS.EC2();
  ec2.describeInstances({
    Filters: [{Name: 'tag-key', Values: ['OperatingSchedule']}]
  }).promise().then((data) => {
    const all = _.flatten(_.map(data.Reservations, (reservation) => reservation.Instances));

    // 以降の処理を記述...
  }).catch((err) => {
    context.fail(err)
  });

次に、稼働時間帯かどうかを判定するフィルター処理を実装します。
この実装は別ファイル lib/schedule-filter.js として作成します。

const _ = require('lodash');
const moment = require('moment');
const REGEXP = /([0-9]{4})-([0-9]{4})\s\((.+)\)/;

/*
 * 現在稼働中であるべきかどうかを Boolean で返す.
 */
module.exports = (instance) => {
  // タグ設定が正規表現とマッチしない場合は、停止しないよう true を返す
  const tag = _.find(instance.Tags, (tag) => {return tag.Key === 'OperatingSchedule'});
  if (!tag) {
    return true;
  }

  // スケジュール設定を取得
  const schedule = tag.Value;
  const values = schedule.match(REGEXP);
  if (!values) {
    return true;
  }

  // 現在日時を取得
  const now = moment().utcOffset('+09:00');

  // 指定された曜日でない場合は false
  if (!_.includes(values[3].split(','), now.format('ddd'))) {
    return false;
  }

  // 稼働時間帯でない場合は false
  const start = now.clone().hour(parseInt(values[1].substring(0, 2))).minutes(parseInt(values[1].substring(2, 4))).seconds(0);
  const end = now.clone().hour(parseInt(values[2].substring(0, 2))).minutes(parseInt(values[2].substring(2, 4))).seconds(0);
  if (start.isAfter(now) || end.isBefore(now)) {
    return false;
  }

  return true;
};

このフィルター処理を組み合わせ、EC2 が稼働時間帯かつステータスが stopped となっている場合に起動するスクリプト start.js を完成させます。
停止スクリプト stop.js は、ステータスの判定 running に変わるのと、startInstancesstopInstances に変わるだけです。

const _ = require('lodash');
const AWS = require('aws-sdk');
const scheduleFilter = require('lib/schedule-filter');

exports.handler = function(event, context) {
  const ec2 = new AWS.EC2();
  ec2.describeInstances({
    Filters: [{Name: 'tag-key', Values: ['OperatingSchedule']}]
  }).promise().then((data) => {
    // 全ての EC2 インスタンスを取得
    const all = _.flatten(_.map(data.Reservations, (reservation) => reservation.Instances));
    // 対象となるインスタンスに絞り込む
    const filtered = _.filter(all, (instance) => {return instance.State.Name === 'stopped' && scheduleFilter(instance);});
    // インスタンスIDのリストに変換
    const ids = _.map(filtered, (instance) => {return instance.InstanceId;});

    if (_.isEmpty(ids)) {
      context.succeed();
      return;
    }

    ec2.startInstances({
      InstanceIds: ids
    }).promise().then((data) => {
        context.succeed(ids);
      }).catch((err) => {
        context.fail(err)
      });

  }).catch((err) => {
    context.fail(err)
  });
};

ちなみに Lambda では、Function の処理が成功の場合は context.succeed();、失敗の場合は context.fail(); をコールします。
詳細は下記公式ドキュメントを参照してください。

Context オブジェクト (Node.js) - AWS Lambda

デプロイタスクの修正

今回は起動と停止の2つの Lambda Function を追加したのと、新たに lib ディレクトリが追加されたため、前回作成したデプロイタスクを少し修正します。

const gulp = require('gulp');
const zip = require('gulp-zip');
const del = require('del');
const install = require('gulp-install');
const runSequence = require('run-sequence');
const awsLambda = require("node-aws-lambda");

gulp.task('clean', function() {
  return del(['./dist', './dist.zip']);
});

// start.js と stop.js をそれぞれコピー
gulp.task('js', function() {
  return gulp.src(['start.js', 'stop.js'])
    .pipe(gulp.dest('dist/'));
});

// lib をコピーする処理を追加
gulp.task('lib', function() {
  return gulp.src(['lib/**/*.js'])
    .pipe(gulp.dest('dist/lib'));
});

gulp.task('node-mods', function() {
  return gulp.src('./package.json')
    .pipe(gulp.dest('dist/'))
    .pipe(install({production: true}));
});

gulp.task('zip', function() {
  return gulp.src(['dist/**/*', '!dist/package.json'])
    .pipe(zip('dist.zip'))
    .pipe(gulp.dest('./'));
});

// deploy を2回実行
gulp.task('upload', function(callback) {
  awsLambda.deploy('./dist.zip', require("./lambda-config-start.js"), () => {
    awsLambda.deploy('./dist.zip', require("./lambda-config-stop.js"), callback);
  });
});

gulp.task('deploy', function(callback) {
  return runSequence(
    ['clean'],
    ['js', 'lib', 'node-mods'],
    ['zip'],
    ['upload'],
    callback
  );
});

再度デプロイすると、起動・停止の2つの Lambda Function が追加されます。

IAM ロールに権限を付与

IAM ロールに対して、スクリプト内で使用している API をコールするために必要な権限を追加します。
今回は ec2:describe-instancesec2:stop-instancesec2:start-instances を使用しているため、以下の設定を追記します。

{
    "Effect": "Allow",
    "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:DescribeInstances"
    ],
    "Resource": "*"
}

Lambda Function の定期実行設定

ここまでの設定で、EC2 の起動・停止が可能となりました。
最後に、自動的に Lambda Function が実行されるよう、イベントソースの設定を行います。

Function の詳細画面にある [Event sources] タブから、以下のイベントソースを新規に追加します。

項目 設定値
Event source type CloudWatch Events - Schedule
Rule name rule-15minutes
Schedule expression rate (15 minutes)

これで、15分に1回定期実行され、自動起動・停止を実現することができました。

まとめ

いかがでしたでしょうか。現在まちいろでは本番環境での Lambda の利用を始めていますが、今後は開発フローをどのようにしていくかが課題だと感じています。

かなり長いエントリとなってしまいましたが、設定自体は非常に簡単なので、興味はあるけどまだ触ったことがないという方は是非挑戦してみてください。

AWS Lambda で EC2 インスタンスを自動起動・停止してみる (セットアップ編)

AWS Lambda Node.js

こんにちは、まちいろの工藤です。

先日の AWS Summit レポートでも

今回の AWS Summit では「サーバーレス」という単語がよく聞こえてきました。

Lambda をうまく利用することで、開発・運用コストの最小化でき、 かつアプリケーションからビジネスロジック以外のコードを切り出すことができる、というのはかなりキャッチーですね。

事例で紹介されていた、EC2 インスタンスを日中だけ起動しておくよう Lambda で制御する、というのは面白いなと思いました。

と触れましたが、今回は事例として紹介されていた「EC2 インスタンス自動起動・停止」に挑戦してみたいと思います。

まずはコンソール画面から触ってみる

Lambda がどんなものか、まずはコンソールから Lambda Function を登録してみたいと思います。
ヘッダメニューのサービスから、[コンピューティング]-[Lambda] にアクセスします。

f:id:mkudo-machiiro:20160615113649p:plain:w400

Lambda Function を追加する

「Step 1: Select blueprint」は【Skip】ボタンを押してスキップします。
次に、「Step 2: Configure function」にて以下の設定を行います。

項目 設定
Name lambda-test
Runtime Node.js 4.3
Code entry type Edit code inline
Handler index.handler
Role Create new role - * Basic execution role

ソースコードには、サンプルとして以下のコードを貼り付けます。
他にも ZIP ファイルをアップロードしたり、S3 に配置した ZIP ファイルを読ませる方法があるようです。

exports.handler = (event, context) => {
  console.log('lambda test');
};

Role のプルダウンを変更すると、IAM ロールの登録画面が別ウィンドウで表示され、Lambda を実行するために必要なポリシーが予め設定された状態となります。
このロールは後ほど使用したいので、名称に EC2_OPERATING_SCHEDULE_MANAGER と付けて保存しておきます。
登録が完了すると、Lambda Function の設定画面側で追加した IAM ロールが選択された状態となります。

以上の設定で Lambda Function を追加します。

動作確認

Lamda Function の詳細画面の【Test】ボタンからテストを実行します。
ここで Function に渡すパラメータを定義可能ですが、今回はサンプル Hello World そのままで実行します。

f:id:mkudo-machiiro:20160615120755p:plain:w400

実行すると、画面下部に実行結果が表示されます。
先ほど貼り付けたコードに記述した console.log の実行結果がログに出力されていれば成功です。

f:id:mkudo-machiiro:20160615121028p:plain:w400

ローカル開発環境の構築

コンソールを触ってみた印象としては、コードの修正・デプロイの流れが面倒そうに感じました。
そこで、ローカルのソースコードを ZIP 化 -> デプロイまでの流れを作ってみたいと思います。

今回はこの要件にぴったりな npm モジュール node-aws-lambda を使用したいと思います。

github.com

gulp セットアップ

まずは node-aws-lambda を使ったデプロイに必要な各種モジュールをインストールします。

$ npm install gulp gulp-install gulp-zip del node-aws-lambda require-dir run-sequence --save-dev

次に gulpfile.js を作成します。
require-dir モジュールを使って、タスクファイルの分割を行っています。

var dir = require('require-dir');
dir('./gulp/tasks', {recurse: true});

node-aws-lambda の README を参考に、デプロイ用のタスクファイル gulp/tasks/deploy.js を作成します。

const gulp = require('gulp');
const zip = require('gulp-zip');
const del = require('del');
const install = require('gulp-install');
const runSequence = require('run-sequence');
const awsLambda = require("node-aws-lambda");

gulp.task('clean', function() {
  return del(['./dist', './dist.zip']);
});

gulp.task('js', function() {
  return gulp.src(['index.js'])
    .pipe(gulp.dest('dist/'));
});

gulp.task('node-mods', function() {
  return gulp.src('./package.json')
    .pipe(gulp.dest('dist/'))
    .pipe(install({production: true}));
});

gulp.task('zip', function() {
  return gulp.src(['dist/**/*', '!dist/package.json'])
    .pipe(zip('dist.zip'))
    .pipe(gulp.dest('./'));
});

gulp.task('upload', function(callback) {
  awsLambda.deploy('./dist.zip', require("./lambda-config.js"), callback);
});

gulp.task('deploy', function(callback) {
  return runSequence(
    ['clean'],
    ['js', 'node-mods'],
    ['zip'],
    ['upload'],
    callback
  );
});

node-aws-lambda 用の設定ファイル gulp/tasks/lambda-config.js を作成します。
role には先ほど作成した IAM ロール EC2_OPERATING_SCHEDULE_MANAGER の arn を指定します。
注意点として、指定した profile に Lambda Function の登録・更新権限を付与しておく必要があります。

module.exports = {
  profile: 'machiiro',
  region: 'ap-northeast-1',
  handler: 'index.handler',
  role: 'arn:aws:iam::xxxxxxxx:role/EC2_OPERATING_SCHEDULE_MANAGER',
  functionName: 'lambda-test',
  timeout: 5,
  memorySize: 128,
  publish: false,
  runtime: 'nodejs4.3'
}

最後に、package.jsonscript に gulp 実行用の設定を追加しておきます。

  "scripts": {
    "gulp": "gulp"
  },

デプロイ

コンソール画面で貼り付けたソースコードindex.js として作成します。
正常にデプロイされたことがわかるよう、ログに出力するメッセージをちょっといじっておきます。

exports.handler = (event, context) => {
  console.log('lambda test2');
};

最終的なファイル構成は以下のようになります。

gulp/
    tasks/
        deploy.js
        lambda-config.js
node_modules/
gulpfile.js
index.js
package.json

デプロイを実行してみます。

$ npm run gulp deploy
> gulp "deploy"

[12:47:12] Using gulpfile path-to-path/gulpfile.js
[12:47:12] Starting 'deploy'...
[12:47:12] Starting 'clean'...
[12:47:12] Finished 'clean' after 8.02 ms
[12:47:12] Starting 'js'...
[12:47:12] Starting 'node-mods'...
[12:47:12] Finished 'js' after 19 ms
npm WARN package.json lambda-test@1.0.0 No description
npm WARN package.json lambda-test@1.0.0 No README data
[12:47:13] Finished 'node-mods' after 716 ms
[12:47:13] Starting 'zip'...
[12:47:13] Finished 'zip' after 28 ms
[12:47:13] Starting 'upload'...
[12:47:14] Finished 'upload' after 597 ms
[12:47:14] Finished 'deploy' after 1.36 s

Lambda の画面から再度テストを実行してみましょう。
ログに出力されるメッセージが変更したものになっていれば、デプロイは正常に動作しています。

まとめ

今回は Lambda を一から触りつつ、gulp をつかってソースコードをデプロイする流れを構築してみました。
次回は、実際に EC2 インスタンスの起動・停止させる部分を実装していきたいと思います。

Gemfileのバージョンとオプション指定についてまとめてみた

Ruby

こんにちは、柏谷です。

弊社ではrubyをアプリケーション開発に採用する事が増えてきて、必然的にbundleやgemの知識が必要となってまいりました。

今回は備忘録もかねて、rubyで開発をする際の入り口ともいえるGemfileの記述方法を記事にしました。

Gemfileを作成

普通にファイルを作成してもいいのですが、bundle initすると自動で生成してくれます。

提供元を指定する

Gemfileの最初には提供元を記載します。

source 'https://rubygems.org'
# 認証が必要な場合
source 'https://user@password:rubygems.org'
# プライベートなリポジトリを指定
source 'https://rubygem.machiiro.jp'

その他の提供元(使った事ない)

rubyのバージョンを指定する

続いて、rubyのバージョンを指定します。

ruby '1.9.1'
# パッチレベルを指定する
ruby '1.9.1', :patchlevel => "376"

RubyのバージョンはMAJOR.MINOR.TEENY+PATCHとなっています。 MINORバージョンは1年に1度クリスマスにあがるとのこと。おもしろい文化ですね。

2.1.0以降のバージョンは、Semantic Versioning 2.0.0に乗っ取って更新されています。

必要なGemを指定する

いよいよ、アプリケーションに必要なgemを羅列していきます。

バージョンの指定

# 常に最新のもの
gem 'activerecord'
# バージョン指定
gem "activerecord", "3.0.0",
# バージョン指定・以上以下
gem "activerecord", ">= 3.0.0", "< 3.1.0"
# バージョン指定・メジャーバージョンは変えない
gem "activerecord", "~>= 3.0.0"

必要とするファイルの指定

# 必要とするファイルを指定
gem 'activerecord', '>= 3.1.0', require: 'active_record'
# 必要とするファイルを指定・複数
gem 'activerecord', '>= 3.1.0', require: ['active_record', 'active_record2']

requirefalseに指定すると、アプリケーションでライブラリを使用する際に、明示的にrequire: gem_nameとしなければなりません。

development用に入れているツールには、production用で不要な自動ロードをさせないため指定する事が多いです。

また、gemの名称とrequireするライブラリの名称が異なる際などにもよく利用されます。

http://stackoverflow.com/questions/4800721/bundler-what-does-require-false-in-a-gemfile-mean

環境の指定(group,groups)

個別に指定する場合

# 環境を一つ指定する
gem 'rspec', group: 'test'
# 環境を複数指定する
gem 'rspec', group: [:test, :development]

グループ毎に指定する場合

# デフォルトでアプリケーションに必要
gem activerecord
# 開発に必要
group :development do 
     gem 'rspec'
group :test do 
# テスト環境に必要
group :test do 
     gem 'rspec'
group :test do 
# 本番環境に必要
group :production do 
     gem 'rspec'
group :test do 

bundle installするときに--withoutオプションをつけると、不要なインストールを避ける事が出来ます。

# 全部インストール
bundle install
# 開発用に必要なモノは除いてインストール
bundle install --without development

gemファイルのパスを指定

ローカルに自前のgemなどがある場合に、pathを指定して読み込む事が出来ます。

gem "rails", :path => "vendor/rails"

プラットフォームを指定

gourpとプロジェクトに必要なgemが、rubyのバージョンやwindows環境などプラットフォームによって変わってくる場合は、プラットフォームを指定してインストールするgemを記載する事が出来ます。

bundle installする際の処理系により判断されます。

gem "weakling",   :platforms => :jruby

gitリポジトリを利用する

gemが公な提供元に属していない場合や、提供元で公開されていない最新のバージョンを利用したい場合、gitオプションでgemを指定することで利用する事が可能となります。

githubとbitbucketに関しては、専用のオプションが準備されています。

# git リポジトリを利用する
# HTTP(S)でダウンロードする場合
gem "rails", :git => "https://github.com/rails/rails.git"
# SSHでダウンロードする場合
gem "rails", :git => "git@github.com:rails/rails.git"

# github のリポジトリを利用する
gem "rails", :github => "rails/rails"

# bitbucketのリポジトリを利用する
gem "rails", :bitbucket => "rails/rails"

皆さんもぜひGemfileを使いこなして、快適なrubyライフを送ってください!