/etc/profile.d/とはなんのためのディレクトリなのか調べてみた

Chefでrbenvをインストールするレシピを書いているのですが、とある参考記事に「bashは/etc/profile.d/以下に配置する」とありました。 「なぜここなの？」と思ったので、メモします。

/etc/profile.d/とは

/etc/profile.d/の役割をいろいろ調べてみたところ、このディレクトリはアプリケーションごとのbashを配置するディレクトリらしいです。

たとえば、rbenvをインストールするなら、そのbashは/etc/profile.d/rbenv.shとなる、ということらしいです。 まあ、慣例なのでその方が分かりやすいですよ〜、程度だと思います（たぶん）。

bashの実行順序

そもそもbashはどう走査されるのか、という話です。 参考記事によると、bashは以下の順序で実行されるようです。

1. /etc/profileを実行
2. /etc/profileによって、/etc/profile.dディレクトリ配下のすべてのファイルを実行
3. ログインユーザーのホームディレクトリにある~/.bash_profileを実行
4. ~/.bash_profileによって、~/.bashrcを実行
5. ~/.bashrcによって、/etc/bashrcを実行

• UNIX処方箋：bashが起動時に実行するファイル - ITmedia エンタープライズ

/etc/profileの中身

上記1-5の2はどういうことよ、と思ったので確認してみました。 /etc/profileの中には、以下のような記述があります。 なるほどな〜、という感じですね。

for i in /etc/profile.d/*.sh ; do
    if [ -r "$i" ]; then
        if [ "${-#*i}" != "$-" ]; then
            . "$i"
        else
            . "$i" >/dev/null 2>&1
        fi
    fi
done

そんな感じでした。 すっきりしました。 めでたしめでたし。

Chef SoloでyumのEPELリポジトリを有効化する方法

Chefでのサーバ構築時に、以下のようなエラーに出くわしました。 たとえばPackage Resourceでlibyamlをインストールしようとすると、

  * package[libyaml-devel] action install
    * No version specified, and no candidate version available for libyaml-devel
================================================================================
Error executing action `install` on resource 'package[libyaml-devel]'
================================================================================


Chef::Exceptions::Package
-------------------------
No version specified, and no candidate version available for libyaml-devel

という感じです。

解決策として、yumのEPELリポジトリを追加すればよいです。

解決策

Cookbookを取得する

yumのEPELリポジトリを追加する手っ取り早い方法として、Opscodeのコミュニティで配布されているクックブックを利用する方法があります。 以下のコマンドをターンッとたたくだけでよいです。

$ knife cookbook site vendor yum

実行の命令を書く

あとはnodes/下のJSONのrun_listにyum::epelを追加するだけです。

{
  "run_list": [
    "yum::epel"
  ]
}

これで、問題なくインストールすることができました。 おしまい。

参考記事

• 開発メモ#5 : Amazon Linux で knife-solo を使って chef-solo 実行 - naoyaのはてなダイアリー

Vagrant上にChef Soloで環境を構築する方法

今、Vagrant上にChef Soloで諸々の環境を自動構築する方法について学んでいます。 今回は、まず簡単な命令を実行できるまでの流れについてまとめます。

Vagrantの初期化〜SSH接続まで

Vagrantを初期化する

まず、Vagrantを初期化してVagrantfileを生成します。 Boxは手元にあるという仮定です。

$ vagrant init [box name]

IPアドレスを設定する

Chef Solo（で使うknife-solo）では~/.ssh/configで設定したホストに対して実行します。 この準備として、まずVagrant側のIPアドレスを設定します。

$ vi Vagrantfile

# config.vm.network :private_network, ip: "192.168.33.10"
config.vm.network :private_network, ip: "192.168.33.10"

Vagrantを起動する

これはupするだけでござる。

$ vagrant up

SSH接続の準備をする

直接~/.ssh/configに記述してもよいのですが、Vagrantにはこれを一発で書いてくれる便利なコマンドがあるので、これを利用します。 upして仮想サーバを起動させないと下記コマンドは実行できないので注意します。

$ vagrant ssh-config —host [host] >> ~/.ssh/config

Chef Soloの準備〜実行まで

Chefをインストールする

とりあえずローカル側にChefをインストールします。

$ gem install chef

Chefの設定をする

以下のコマンドで設定します。 質問はすべてデフォルトでOKらしいです（無責任）。

$ knife configure

knife-soloをインストールする

Chef Soloをつかうにはknife-soloをインストールします。 これはgemでサクッとインストールできます。

$ gem install knife-solo

Chefリポジトリを作成する

Chefはリポジトリ単位で管理していきます。 まずこれを作成します。

$ knife solo init [repository name]

ノード側にChef Soloの準備をする

knife-soloは、ノード側（各サーバ）上でChef Soloを実行します。 なので、ノード側にChef Soloの実行環境を用意しなければなりません。

これは、以下のコマンドで簡単に実行できます。

$ knife solo prepare [host]

クックブックを作成する

サーバの設定はクックブックに書いていきます。 これは以下のコマンドで生成できます。

$ knife cookbook create [cookbook name] -o site-cookbook

実行する

自分好みに編集が完了したら、以下のコマンドで実行します。 おわり。

$ knife solo cook [host]

例：iptablesを無効化する

Vagrantはデフォルトでファイアウォールが設定されています。 なので、これを無効化しないとWebサーバを構築してもWebブラウザからアクセスできません。 今回はこれを例として書いてみます。

本番環境では役に立たないレシピですね。。。

クックブックを作成する

サクッと作成します。

$ knife cookbook create iptables -o site-cookbooks

レシピを編集する

レシピの書き方は、ググってみるといろいろあるので、そちらを参考にします。 今回はとりあえず中身だけ。

$ vi site-cookbooks/iptables/recipes/default.rb

service 'iptables' do
  action [:disable, :stop]
end 

run_listを編集する

レシピを編集したら、「iptablesを実行してくれ！」という指示を出さなければいけません。 これは以下のファイルのrun_listに書きます。

$ vi  nodes/[host].json 

{
  "run_list": [
    "iptables"
  ]
} 

実行する

あとは以下のコマンドで実行します。

$ knife solo cook [host]

だいぶはしょりましたが、以上で実行できます。 次はChef SoloでRailsの環境を自動構築する方法を書く……ために、今から勉強しますOnz

Vagrant上でRuby on Railsを動作させる方法

最終的にはgit cloneしてvagrant upしたらRailsが動くところまでやりたいのですが、今回はまずVagrant上でRailsを動作させてみます。 あらかじめ、VirtualBoxとVagrantをインストールしておく必要があります。

• Oracle VM VirtualBox
• Vagrant

Railsの作成〜Vagrantの起動まで

ローカル側でRailsを作成する

まず、ローカル側でRailsを作成します。 Rails自体はローカル側ではなくVagrantで動かすので、bundleはいりません。

$ rails new hoge --skip-bundle
$ cd hoge

Vagrantの初期設定をする

次に、ローカル側にVagrantのBoxを追加します。 Boxとは言ってみればOSのテンプレートのようなものです（たぶん）。

以下のサイトにBoxがたくさんあるので、すきなものをaddします。

• Vagrantbox.es

たとえば、上記サイトで配布されているCentOS 6.4をcentos64という名前で追加するには、以下のように実行します。

$ vagrant box add centos64 http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130731.box
$ vagrant init centos64

ポートフォワーディングの設定をする

Vagrant上で動かすRailsのポート番号はデフォルトで3000番です。 そのため、ローカル側からhttp://localhost:3000/でアクセスしたときに、Vagrant側でRailsの3000番に割り当てる必要があります。

これは、vagrant init実行時に生成されたVagrantfileという設定ファイルから編集できます。

# config.vm.network :forwarded_port, guest: 80, host: 8080
config.vm.network :forwarded_port, guest: 3000, host: 3000

Vagrantを起動する

以下のコマンドでVagrantが起動します。

$ vagrant up

仮想サーバの設定

VagrantにSSH接続する

まず、Vagrantに接続します。

$ vagrant ssh

ファイアウォールを停止する

次にファイアウォールを停止します。 こうしないと、Railsで用いる3000番を受け付けてくれません。

$ sudo service iptables stop
$ sudo chkconfig iptables off

あるいは、3000番を受け付けるようiptablesに記述してもよいと思います。 ローカルなので、offでいいと思いますが。。。

yumでいろいろインストールする

yumをつかって、いろいろとインストールします。 makeとかgccとかはデフォルトで入っているようですが、正直なにが必要かわからないので、必要そうなものを適当にyum installします（すみません）。

$ sudo yum -y update
$ sudo yum -y install make gcc curl-devel libyaml-devel openssl-devel readline-devel zlib-devel git

rbenvをインストールする

今回はrbenvをつかってrubyをインストールするので、以下のようにrbenvをインストールします。

$ git clone git://github.com/sstephenson/rbenv.git ~/.rbenv
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ source ~/.bash_profile

ruby-buildをインストールする

rbenvをつかうにはruby-buildも必要なので、あわせてインストールします。

$ git clone https://github.com/sstephenson/ruby-build.git ~/ruby-build
$ sudo ~/ruby-build/install.sh

rubyをインストールする

では、rubyをインストールします。 rbenv installまで打ってTAB2回押しでインストール可能なリストが表示されるので、安定版を適当にインストールします。

$ rbenv install 2.0.0-p353
$ rbenv global 2.0.0-p353

gemを設定する

次にgemの設定をします。 Railsではbundlerをつかうので、これをインストールします。 インストールし終えたら、rbenv rehashするのを忘れません。

$ gem update --system
$ gem install bundler
$ rbenv rehash

Railsの設定

bundle installの実行速度を早くする

Vagrant上でbundle installをするとものすごく遅くなるときがあります。 これは、以下のように設定することで解決します。

$ sudo vi /etc/resolv.conf

; 以下を追記する
options single-request-reopen

• Vagrant+VirtualBox（CentOS6）で「gem install rails」がすっごい遅い時の対処法 | IDEA*IDEA

vagrantフォルダに移動する

ローカル側のVagrantfileがあるフォルダは、Vagrant内の/vagrantと共有されています。 この場所でRailsを起動するので、移動します。

$ cd /vagrant

Gemfileを編集する

gemのtherubyracerというJavaScriptの実行エンジンがないとエラーが起きてしまいますので、Gemfileの設定を変更します。 ローカル側からでも、Vagrant上からでも大丈夫です。

# gem 'therubyracer', platforms: :ruby
gem 'therubyracer', platforms: :ruby

Railsを起動する

以下のコマンドで実行できます。

$ bundle exec rails s

Webブラウザで表示する

あとは、Webブラウザでhttp://localhost:3000/にアクセスすると、ページが表示されます。 おめでとうございます（自分に対して）。

さて、いまからChefの勉強です。。。

参考サイト

• #292 Virtual Machines with Vagrant - RailsCasts
• vagrantでCentOSのVMを立ちあげて、ネットワークが遅い時に試すこと - $shibayu36->blog;
• はじめてのvagrant ruby on rails その6 localhostで開くあき | あき
• localhost:3000に接続できません[vagrant centos rails] | はらぺこ屋
• vagrantにrails環境を作ったがポート3000でアクセスできなかった: こねこの杜　クリエイターの日記

Gitのブランチの運用ルール

以下のページを参考に、自分なりに分かりやすいようにまとめてみました。 「こうした方がいいのでは」という知見も入れるべきなのでしょうが、まともに開発したことがないので今回は勘弁してください。。。

• 見えないチカラ: A successful Git branching model を翻訳しました
• 原文：A successful Git branching model » nvie.com

しばらくこれで運用してみて、自分なりに運用ルールをブラッシュアップしていきます。

ブランチ一覧

基本的に以下のブランチのみで運用します。

• master
• develop
• feature/*
• release/*
• hotfix/*

master/developには直接コミットせず、マージのみにより変更します。

各ブランチについて

フィーチャーブランチ

分岐元	マージ先	ブランチ名
develop	develop	feature/*

新しい機能を開発するときは、基本的にフィーチャーブランチを切って開発します。 開発が完了したらdevelopブランチにマージし、フィーチャーブランチは削除します。

フィーチャーブランチの作成

$ git checkout -b feature/hoge develop

developブランチにマージ

$ git checkout develop
$ git merge —no-ff feature/hoge
$ git branch -d feature/hoge
$ git push origin develop

リリースブランチ

分岐元	マージ先	ブランチ名
develop	master/develop	release/*

次のリリースが決まったら、リリースブランチを切って開発します。 開発が完了したらmaster/developブランチにマージし、リリースブランチは削除します。 また、masterブランチにはタグをつけます。

リリースブランチの作成

$ git checkout -b release/1.0 develop

masterブランチにマージ

$ git checkout master
$ git merge —no-ff release/1.0
$ git tag -a 1.0
$ git push origin master
$ git push origin 1.0

developブランチにマージ

$ git checkout develop
$ git merge —no-ff release/1.0
$ git push origin develop

リリースブランチを削除

$ git branch -d release/1.0

ホットフィックスブランチ

分岐元	マージ先	ブランチ名
master	master/develop	hotfix/*

masterブランチに致命的なバグが発生したら、ホットフィックスブランチを切って修正します。 修正が完了したらmaster/developブランチにマージし、ホットフィックスブランチは削除します。 また、masterブランチにはタグをつけます。

ホットフィックスブランチの作成

$ git checkout -b hotfix/1.0.1 master

masterブランチにマージ

$ git checkout master
$ git merge —no-ff hotfix/1.0.1
$ git tag -a 1.0.1
$ git push origin master
$ git push origin 1.0.1

developブランチにマージ

$ git checkout develop
$ git merge —no-ff hotfix/1.0.1
$ git push origin develop

このとき、リリースブランチが存在していたら、developブランチではなくリリースブランチにマージします。

ホットフィックスブランチの削除

$ git branch -d hotfix/1.0.1

ブランチモデルの図

ライセンス明記を条件に再配布可能とのことなので、前述の原文にある図を以下に示します。 上記内容が可視化されていて分かりやすいです。

ライセンス

Author	Original blog post	License
Vincent Driessen	http://nvie.com/archives/323	Creative Commons

Gitのブランチ名をタブで補完する方法

Gitでブランチ名を指定するとき、補完ができるといいなぁと思ったので、設定してみました。

ブランチ名を補完する方法

git-completion.bashを取得する

Gitでブランチ名を補完するには、git-completion.bashが必要となります。 GitHubに上がっているので、ホームフォルダなどに.git-completion.bashといった名前で保存します。

• https://github.com/git/git/blob/master/contrib/completion/git-completion.bash

sourceコマンドで実行する

あとは、上記bashファイルをsourceコマンドで実行するだけです。

source ~/.git-completion.bash

試しに、ローカルリポジトリ上で補完を試してみてください。

.bash_profileに読み込み指定を書く

毎回のログイン時に自動で読み込むように、以下のように記述します。

$ vi ~/.bash_profile

source ~/.git-completion.bash

これで、長いブランチ名でも怖くないですね。

参考にしたのは以下の記事です。 とても助かりました。。。

• bashでgit補完機能を有効にする方法 - tagamidaiki.com

AWSのS3の使い方（設定〜ファイルのアップロードまで）

S3にファイルをアップロードしたり、Webサイトを公開する方法をまとめます。

S3の設定をする

S3 Management Consoleを開く

• https://console.aws.amazon.com/s3/

Bucket作成画面を開く

EC2やRDSにおけるインスタンスのようなものとして、S3ではBucketとよばれるオブジェクトがあります。 S3を利用する際は、このBucketを作成していきます。

これは、『Create Bucket』より行なえます。

Bucketを作成する

Bucketを作成するのはとても簡単で、単に名前を決めるだけです。 ただ、この名前は他のユーザに取得されているとNGなので、取得されていない名前を設定します。

また、リージョンはTokyoに設定します。 なぜなら日本に住んでいるからです。

画像をアップロードする

作成したBucketを選択する

S3 Management Consoleを開くと、作成したBucketがリストに表示されているので、それを選択します。

画像をアップロードする

『Upload』というボタンから画像をアップロードできます。 適当な画像をアップロードします。

画像のURLを確認する

アップロードした画像を右クリックし、『Properties』を選択します。 すると、右側に『Link』としてURLが表示されます。

ただ、アップロードしたままの状態だと、パーミッションのせいで画像にアクセスすることができません。

外部からアクセスできるようにする

画像を表示させるには、公開用の設定を行なう必要があります。 画像を右クリックし、今度は『Make Public』を選択します。

すると、先ほどのリンクから画像を表示することができるようになります。

長くなりそうなので、Webサイトのホスティングについては次の記事でまとめます。 もはや学習より記事化してる方が時間かかっていますが、気にしてはいけないのです。