Drowsy Dog's Diary

any note, any thought

2013年6月12日
by kazoo
0 comments

Redmineサーバの移行

ローカルの Ubuntu 12.04 + nginx + unicorn + mysql で運用していた Redmine を、
クラウドの Ubuntu 12.04 + apache2 + mysql 環境に移してくれというご依頼。

結論から言うと「Redmine の rails フォルダをまるっとコピー」で済ませたのですが。

その前にいろいろやってみたことメモ。
自分用。

Passenger

移行先はほぼクリーンだけど、すでに Apache + MySQL で社内ドキュメント Wiki みたいなのが動いていた。
ので、nginx 共存よりは Apache + Passenger がいいのかな、ということで。導入お勉強。

rbenv

いらんかもしれんけど、システムワイドな .rbenv を入れてみる。
参考:http://qiita.com/items/8e973a544b592376a07e

ここで dev は全員が所属しているグループ名。

各員、.bashrc などに以下を記述しておく。

ruby-build をインストール。

ruby1.93 をインストール。

OK.

apache2 + passenger

Apache2関連モジュールと Passenger のインストール。

このとき足りないパッケージがあれば passenger が教えてくれる。
apache2 の conf に書く内容も教えてくれる。

ということで、この3行を、
/etc/apache2/sites-available/redmine
としてコピー。

Redmine(略)

http://madroom-project.blogspot.jp/2012/12/ubuntu-1204redmine-220apache.html
Ubuntu + Apache + Passenger + Redmine は、ほぼこちらの内容で OK でした。感謝。

あとは database.yml と configuration.yml を現状に合わせて、とりあえず新環境での Redmine 稼働は OK。バージョンは 2.2.0。

データ移行

さて、MySQL データ移行。
DBよく知らないけどたぶん export して import すればいいんだろー、と思ってぐぐってやってみた。
http://fmkt.blog65.fc2.com/blog-entry-7.html
http://napzak.com/tips/?MySQL%E3%81%AE%E3%83%80%E3%83%B3%E3%83%97%EF%BC%88%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%9D%E3%83%BC%E3%83%88%EF%BC%89%E3%80%81%E3%82%A4%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%88%E3%80%81%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97
mysqldumpを使う。ふむふむ。

旧サーバで、

引越し先で

結局

おお。あっさりコピーできた。。と、ぱっと見は思ったのだけど、いざ既存のチケットを操作しようとするとエラーが出たりして、不整合があるらしい。何度かやってみるも結局そこで時間切れ。

最終的には旧 Redmine の rails 環境をそのまま /usr/local/redmine-old に持って来て、

してしまいました。やや不完全燃焼。。。

2013年6月10日
by kazoo
0 comments

Kindle for Mac が Amazon.co.jp のアカウントに未対応だった

えーー。
kindleformac
前々回の Chef の記事などは、『入門Chef Solo – Infrastructure as Code』の Kindle 版を読みつつ書いていたのですが、このときうっかり Kindle Paperwhite さんを会社に忘れておりまして。仕方ないので iPhone の Kindle アプリで読みつつ執筆していました。
しかし、iPhone サイズでぱらぱら読むのもなかなか辛い(特にプログラムコード)ので、Mac 用ってないんかいな、と思ったらあった
あったのに。

アプリの日本語化はされてるけど、ログインは Amazon.com のアカウントでしかできないらしい。当然 Amazon.co.jp で買った Kindle コンテンツは閲覧できない。
で、ぐぐってみると、US と JP アカウントの結合をしてやれば読めるようになるとの記事もあるので、じゃあやってみるかと Amazon.com のアカウントを作ったのですが。。

アカウント結合に関する注意点 – Amazon.co.jp

  • Amazon.co.jpで販売されていないKindle端末、およびKindle無料アプリ(Kindle for PC、Kindle for Macなど)での日本語コンテンツの利用はできません

あかんやん。
システムの壁なのか、商慣習の壁なのか知らないけど、iPhone/iPad の無料アプリで普通に読めるコンテンツを、なぜ Mac で読ませちゃいけないのかぜんぜんわからん。
改善してほしいものですねぇ。

2013年6月7日
by kazoo
0 comments

Ubuntu の resolveconf

先日のネットワークトラブル再発。
内部ネットワークで Redmine や Gitlab が走っているサーバに唐突に繋がらなくなった。

前回同様にローカルネットワークには ping 疎通するものの、外に出て行けない。
さらに前回と違って、$ nslookup yahoo.com もダメで、DNS も引けていない様子。
と、見ると /etc/resolve.conf が空っぽだった。

で、調べると、Ubuntu って起動時に resolve.conf を生成するのですね。その元ファイルは、
/etc/resolveconf/resolve.conf.d/base
に、

のように書いてやって(うちのネットワークの場合)

と、してやれば resolve.conf が更新されるらしい。

とりあえず直ったけど、根本原因を見つけんといかんなぁ。

参考:
http://blog.libero-tecnologia.net/?p=6

2013年6月6日
by kazoo
1 Comment

Chef-solo, knife-solo 導入メモ

Chef-solo やってみたメモー。(語尾)

伊藤直也さんの『入門Chef Solo – Infrastructure as Code』[kindle版]を購入して早数ヶ月、ようやく動かしながら読み進め始めた。ので整理しつつメモ。

自分のための概念言い換えメモが多いです。
とりあえず Chef 使いたいという人は入門 Chef-solo 買いましょう。必読書と思います。

今回は #6 くらいまでの内容。

Chef, Chef-solo

Chef は、サーバの設定や更新を自動化するツール。Rubyで記述された「サーバのあるべき状態」(レシピという)に基づいて、アーキテクチャに依らずそれを一定に収束させるフレームワーク。

大規模環境では Chef-server & Chef-client という組み合わせで、多数のホストにインストールされたクライアントがサーバから設定を取得して一気に設定を行うが、そこまで必要無いというケースのためにスタンドアロンのコマンドとして実装されたのが Chef-solo。レシピの記述方法などはどちらも同じ。

「サーバ設定手順書」を読み書きしたことのある人なら、何らかの恩恵を得ることができる。きっと。

knife, knife-solo

knife は Chef に含まれるツール。リポジトリを操作する(後述)。
knife-solo は knife のプラグイン。リモートのサーバにレシピを転送して chef-solo を実行するという機能を、knife に付加する。

用語

Chef は個性的で新しい言葉が多い。シェフ(料理人)とレシピというメタファーに基づいて、ナイフやキッチン、クックブックなどの言葉が次々出てくるのだけど、どうもその喩えがうまく効いてない気がして捉えにくい。。まあ、 naoya さんも書いてるように、最初はあまり気にせず Resource の書き方だけある程度身体で覚え、迷ったときに概念に戻ってくるのが良いのだと思う。
というわけで戻ってくるためのメモ。読み飛ばし可。

  • Repository(Kitchen)
  • Chef の実行に必要な一連のファイルをまとめた入れ物。レポジトリあるいはキッチン。
    キッチンは(普通の)お家にひとつ。というわけで、あるシステムにひとつ、くらいの粒度。
    Chef で何かやろうと思ったらまずレポジトリをつくる。

  • Cookbook
  • 特定のレシピに必要なデータをまとめた入れ物。
    ファイルに対するディレクトリ、クラスに対する namespace のようなもの。

  • Recipe
  • サーバで実行する内容を定義したもの。Ruby の DSL で記述する。

    レポジトリ>クックブック>レシピ

    という階層でレシピ群は管理される。

  • knife
  • レポジトリを操作するためのツール。knife コマンドを使って cookbook を作る(メタファーが破綻してる気がするが)。

  • Resource
  • レシピ内に書く命令のこと。レシピは Ruby で書くが、これらは Chef が提供する DSL。package(パッケージ管理)、service(デーモン管理)、template(設定ファイル管理)、コマンド実行などが用意されている。

    Resource 一覧:http://docs.opscode.com/resource.html

  • Template
  • Resource に記述された設定ファイル(nginx.confとか)を生成するテンプレートファイルのこと。中身は erb。

  • Attribute
  • テンプレートファイル内に変数として記述され、実行時に指定される値のこと。
    たとえば実行ごとに nginx のポート番号を指定したいとしたとき、/etc/nginx.conf のもととなるテンプレートファイル nginx.conf.erbの中に、テンプレートタグを用いて記述する。

  • Node
  • Chef から見た管理対象サーバのこと。

  • Node Object
  • Chef の実行時に渡される JSON ファイルに記述されたプロパティのこと。
    実行するレシピ(= run_list)や、上述の実行時 Attribute などを json 形式で指定する。

  • run_list
  • Node に対して適用するレシピを指定したリスト。

インストール

ようやくインストール。環境は、

  • Mac OSX 10.7.5
  • Chef: 11.4.4
  • knife-solo: 0.2
  • vagrant: 1.0.7
  • ruby: 1.9.3-p392 (rbenv)

で、基本的にはひとつ前の記事で紹介した Vagrant の CentOS-6.3 環境を使い、そこにレシピを流し込むために、knife-solo を使用します。操作方法としては、EC2 でもローカルの VM でも同じです。

対象サーバにログインしてそこで Chef を実行するのが基本、knife-solo によってリモートからそれを実行するのが応用になるかと思いますが、前者については『入門 Chef-solo』などを参照してください。

導入

rubygems で Chef をインストール。

すると knife というツールがインストールされます。まずはこれの初期設定。

いろいろ聞かれるけど、すべてデフォルトで OK。
~/.chef/knife.rb に、設定ファイルが作成されます。

さらに knife-solo をインストール。

現時点では、安定版 0.2.0 がインストールされます。
(『入門Chef-solo』では 0.3.0 が推奨されているのですが、とりあえず)

レポジトリ作成

レポジトリ>クックブック>レシピ、という構成でレシピ群は管理されるのでした。
まず knife-solo コマンドを使って chef-repo というレポジトリを作ってみます。

「サーバの状態定義の集まり」であるレポジトリをバージョニングすることで、管理や共有が楽になります。
ということで、git 配下に。

レポジトリの中身はこんな感じ。

cookbooks と site-cookbooks が、クックブックの置き場所になります。前者にはサードパーティ製のものを、後者に自分の作ったクックブックを格納するのがお作法なようです。Opscode community などには、たくさんのサードパーティ製クックブックが公開されています。
今回は自作のものを置いてみます。

クックブックの作成

mybook というクックブックを作ってみます。
knife コマンドで出力先を指定して、

で、OK。
git add/commit を忘れずに。

仮想サーバの準備

管理対象サーバは、前回記事で立ち上げた Vagrant box を使います。
新規に仮想サーバを作るなら任意のディレクトリで vagrant init して、さらに Host Only Network を有効にして SSH ログインできるように、下記のようにコンフィグを ~/.ssh/config に追記しておきます。

ここで aqua は任意のホスト名です。これによって仮想サーバ aqua に対して knife-solo が SSH 経由で chef-solo を(sudo 権限で)実行できるようになります。

次に、さきほどの chef-repo フォルダに戻って、knife solo prepare を実行します。これは対象サーバに外部から Chef の環境をインストールするコマンドです(実は Vagrant box の多くにはすでに Chef 環境が入っているのですが、念のため最新を準備するためにやっておいた方がよいです)。

OK。nodes フォルダの下に、ホスト名が付いた .json ファイルができました。これが上述の Node Object を記述するファイルであり、実行するレシピなどをこれによって指定します。

レシピ作成

いよいよレシピ作成です。現時点のフォルダ構成は、

先ほど作った mybook クックブックが、そしてその下に default.rb という名前のレシピが見えます。
まずは試しに Apache のインストールだけを行うレシピを書いてみます。

site-cookbooks/mybook/recipes/default.rb

これだけ。
“package”, “service”というのが用語のところで出てきたパッケージやデーモン管理用の Resource になります。構文的にはそれぞれ見たまんまですね。
では、このレシピを流してみます。実行するレシピの指定は、nodes フォルダにある json ファイルで行います。

nodes/aqua.json

これだけ。

レシピ実行

いよいよ実行です。

うまくいったっぽい。ログインして確認してみます。

成功。httpd がちゃんとインストールされて起動もしています。

とりあえず今回はここまで。
Resource の詳細、Template や Attribute の使い方、サードパーティ製クックブックの導入などについては(たぶん)次回。

参考:
http://magazine.rubyist.net/?0035-ChefInDECOLOG
http://tsuchikazu.net/chef_solo_start/

2013年6月5日
by kazoo
1 Comment

Vagrant

Vagrant を触ってみたメモー。(語尾キャラ)
最初は 入門Chef Solo – Infrastructure as Code[kindle版]を読みつつ Chef についてメモ書きをしながら一緒に書くつもりだったのだけど、かなり長くなってきたので先に Vagrant だけ分けることにしました。
とはいえ naoya さんの紹介以上の情報は無いですが。。

Vagrant

ローカル環境に簡単に仮装サーバを構築・削除できるツール。rubygems として提供されている。(Oracle Virtualbox が別途必要)
サーバ自動設定・更新ツールである Chef と直接関係は無いが、ちょっとしたレシピの実験に VM を立てて実験するのに非常に有用で、Chef との連携もよく意識して作られている。

環境

  • Mac OSX 10.7.5
  • vagrant: 1.0.7
  • ruby: 1.9.3-p392 (rbenv)

インストール

まず Virtualbox を普通に DL & インストールしましょう。
その後 vagrant をインストール。

Vagrant はあらかじめ用意された OS イメージの雛形(Box)を利用して VM を構築します。
http://www.vagrantbox.es/ に、大量の box が用意されています。

ここでは Chef-solo 入門に倣って、CentOS-6.3 の Box を利用します。よ。

add できたら仮装サーバの起動。適当なディレクトリを作って、そこで vagrant init

init によって、Vagrantfile という設定ファイルがそのディレクトリに作られます。
ネットワーク設定や Chef レシピの設定、また複数の Box があるときに元になる Box を指定したりします。

そして vagrant up で起動。

たったこれだけでローカルにまっさらな仮想サーバ環境が立ち上がります。すげえ。

デフォルトでは、上記の場合
~/VirtualBox VMs/mybox_xxxxxxxx
といった場所に仮想イメージができる模様です。

で、VM にログイン。vagrant ユーザは sudoers なので、sudo yum install などして自由に構成できます。

で、VM の停止。

で、VM の削除となります。
2回目以降は add や init は必要なく、作って実験して壊して…が極めて簡単にできるようになります。

Sahara

さらに、sahara というライブラリを使うことで、EC2 のスナップショットを取るように、ある時点の仮装サーバの状態を記録・ロールバックということができます。

いずれも動くには動いたのですが、うちの環境では $ vagrant sandbox commit/off にものすごい時間がかかってしまっていまいちでした。MacbookAir ではシンドイのだろうか。
その前にいったん $ vagrant halt して、VM を停止させてから実行すればよい、という情報もありましたが、そうするとせっかくのお手軽さが失われてしまうような気も。
まあ今のところは仮装サーバの立ち上げと破棄がさくさくできるだけで十分かなと。

Chef については次の記事で。

参考:
http://www.ryuzee.com/contents/blog/4292