Drowsy Dog's Diary

any note, any thought

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年5月30日
by kazoo
0 comments

稼働中 EC2 インスタンスの EBS ボリュームのサイズ変更

基本だけど、胃を痛めながらやったのでメモ。

稼働中の EC2 インスタンスで EBS(Root Device) のサイズを変更。
基本的に、現在の EBS からスナップショット作成→スナップショットから新規 EBS ボリューム作成 → 新しいボリュームをアタッチして再起動、という流れ。

>>>続きを読む

2013年4月1日
by kazoo
0 comments

ローカルの Ubuntu12.04 から Amazon S3 へバックアップ

Déjà Dup を使うのが簡単

Déjà Dup は、コマンドラインのバックアップツール duplicity の簡易 GUI 版です。

SystemSettings

左下のやつ。
システムメニューになければ

してから、管理画面を立ち上げ。

また、デフォルトではバックアップ先として S3 が含まれていないので、
Python の AWS インターフェースである boto をインストールしておきます。

バックアップ設定

backup_003
Storage タブの Backup location の選択肢に Amazon S3 が出てきます。
ここに S3 のアクセスキー ID を入力しましょう。バックアップには AWS のアクセスキーとシークレットアクセスキーが必要になります。これらの情報は、AWS にログインして、右上の「アカウント/コンソール」から Security Credentials で確認できます。
また、バックアップ先のフォルダはここで指定できますが、Deja Dup が S3 で使う Bucket は、GUI からは指定できない模様。Bucket を変更するためには、少し古い情報(deja dup ver.19.0)ですが、このあたりが参考になります。

backup_001

次に、バックアップされるフォルダと無視するフォルダ種別を設定。
個人のバックアップだけならデフォルトのままで良いかと思います。ここでは全員分の /home と、システムワイドな設定を含めて /etc と /var もバックアップすることにします。

Schedule タブでバックアップ間隔や期間を設定したら、Overview タブに戻って、とりあえず “Back Up Now”してみます。

backup_002

すると、AWS のアクセスキーとシークレットアクセスキーを聞かれるので、双方を入力。
さらに暗号化する場合のパスワードなど設定し、問題なければバックアップが始まります。
2回目からは差分バックアップになる模様。

レストア

レストアはちゃんと試していないので未確認ですが、同様に GUI ツールから “Restore…”ボタンでレストアするバックアップ元と日時など指定してレストア。このとき注意するのは、そのファイルに対して書き込み権限が無ければレストアに失敗する、ということです。自分の home だけならいいけど /etc などは一般ユーザではレストア不可(上書きするので当然ですが)。
なので、sudo が使えるならコマンドラインから、

するか、

して、root 権限で GUI を立ち上げてあげれば良さそうです。

2012年10月3日
by kazoo
0 comments

AmazonEC2+EBSにsubversionリポジトリを置く

[お題]

現在数名で使っているデスクトップLinux上のsvn、定期バックアップは取っていますが、かなりHDDが圧迫されていること、またいい加減ボロくて怖いので、一部クラウド化を検討したい。
Amazon EC2でsubversion用のインスタンスを稼働させ、リポジトリは Amazon EBS(Elastic Block Store)上に展開します。

参考にさせていただきました。

■Amazon EC2/S3の使い方目次
http://d.hatena.ne.jp/dkfj/20080222/1203658623

■Amazon Elastic Block Store (EBS)上に、Subversionのリポジトリを置く
http://d.hatena.ne.jp/dkfj/20080907/1220771766

■AmazonEC2へsvnリポジトリ作成
http://d.hatena.ne.jp/oyama1102/20110914/1315955862

■’AuthzSVNAccessFile’, perhaps misspelled or defined …..
http://www.svnforum.org/threads/38266-AuthzSVNAccessFile-perhaps-misspelled-or-defined

日本語オフィシャルはこちら

http://aws.amazon.com/jp/ec2/

http://aws.amazon.com/jp/ebs/

 

[前提]

  • 適当なAmazon EC2インスタンスを作成
    ここでは Amazon Linux AMI 64bit。リージョンはAsia Pacific(Tokyo)、必要に応じて接続元のIP制限などセキュリティグループを設定
  • Elastic IP を Allocate して上で作成したインスタンスとAssociateする
  • Elastic Block StoreのVolumeを作成、上で作成したインスタンスにAttachする
    Snapshotは設定しない
  • ここまでを EC2 の Web Console から行う

以下はコンソールで。

Elastic IP のアドレスに ec2-user でログイン。

とりあえず yum をアップデート。

EBSボリュームを ext3 でフォーマットして /svn にマウントする。
デバイスがどのようにマッピングされているかは、AWSコンソールの Attachment Information から見る事ができます。

確認。

念のためインストールされていないことを確認して、subversion と mod_dav_svn をインストール。

リポジトリを作ります。まずはサンプル。

さらにtrunk, tags, branchesと必要なディレクトリを作る。

apacheとの連携ファイルを編集。

以下を追記する。

Basic認証ファイルを作成

認証用設定ファイルを作成。

以下を記述する。

ファイル属性をapacheグループに変更して、httpd を再起動。

おや?

mod_dav_svn を Apache の設定で LoadModule していませんでした。。

適当な場所に、以下を追記してあげます。

mod_dav_svn は、Apache と subversion を結び付けるモジュールです。
この設定ディレクティヴについては、こちらのサイトが詳しいです。

また、以下も同じく httpd.conf に追記します。
mod_authz_svn は、Apache サーバを通して提供される Subversion リポジトリに、パスベース認証を設定します。(参考

再度の再起動。今度こそOK。
最後に、ec2-user が apacheグループじゃない場合は、追加してやる。

外部から接続テスト。SVN_SSH を設定してから、svnコマンドを通す。

長くなりました。
次は Amazon S3 を使ったバックアップなど検討したい。