Bash Tips
最近、短期間に大量のサーバに設定をいれるという仕事がたんまりきていて、とてもじゃないけど手作業なんてしんどいので、ちまちまと使い捨てスクリプトを書いて作業を楽にしてます。
そんな中『これは使える！』というスニペットを残しておきます。
seqコマンド
seqコマンドは順番で数字を出力するだけなんですが、使い勝手よくてちょくちょく使ってます。
$ seq 3 #1から3までの整数を出力 1 2 3 $ seq 2 5 # 2から5までの整数を出力 2 3 4 5 $ seq 4 2 8 # 4から2ずつ8まで出力 4 6 8 $ seq -w 5 100 # -wをつけると桁の幅を同じにできる 005 006 007 009 010 ... ... 100 $ seq -s " " 5 # -sで区切り文字を指定できる 1 2 3 4 5 $ seq -f "hoge%02g.log" 3 # 他の文字列と合わせて出力 hoge01.log hoge02.log hoge03.log $ for i in $(seq 3); do echo "do something"; done do something do something do something
source コマンド
bashでテンプレートエンジンもどきみたいなことをしたい時とかに使います。
#!/bin/sh string="Hello World!!" source test.txt
test.txt
cat << EOF
<html>
<head>
This is a test.
</head>
<body>
${string}
</body>
</html>
EOF
list fileの読み込み
リストファイルを一行ずつ読んで何かにしたい時に。
$ while read line do; echo ${line}; done < list.txt
配列に要素を追加する
array=() # 配列定義
array=(${array[@]} "fuga")
文字列置換
サーバをコピーして、中の設定ファイルを書き変えたい時に。
$ sed -i "s/hoge/fuga/g" /etc/hosts
RHEL6系/CentOS6系のファイルパーミッションのdot「.」をなくす方法
RHEL6系/CentOS6系から、selinuxの管理下にあるファイルにはファイルパーミッションにdot「.」がつくようになってます。
[root@localhost ~]# ls -ld /etc drwxr-xr-x. 57 root root 4096 Jan 4 13:21 /etc
selinuxを無効化しても、元々あったファイルにはドットがついたままなので、
なんか気持ち悪い感じ…。
いろいろ調べたら、ファイルの拡張属性security.selinuxが残ってるのが原因っぽいです。
- Easy way to remove SELinux permissions?
- centos - Why does getfattr not display anything for a file that has the extended attribute bit set? - Server Fault
このdot「.」を消すためには、ファイルの拡張属性を設定するsetfattrコマンドを使います。
[root@localhost ~]# getfattr -m - /etc getfattr: Removing leading '/' from absolute path names # file: etc security.selinux [root@localhost ~]# setfattr -x security.selinux /etc [root@localhost ~]# getfattr -m - /etc [root@localhost ~]# ls -ld /etc drwxr-xr-x 57 root root 4096 Jan 4 13:21 /etc
全ファイルに対して設定する場合は下記を実行します。
（再帰的にコマンドを実行するオプションがないので、findでごりっとやってます。）
# find / -exec setfattr -x security.selinux {} \;
VagrantのBase Boxを作ってみた。CentOS6.3 x86_64編
Vagrantは、Virtual BoxのVM（仮想サーバ）管理を簡単にするためのツールです。
VMを、コマンドラインから起動、停止、削除、etcできるので、テストや開発環境作成などでかなり重宝します。
今回はそのテンプレートになるBase Boxを作ってみたので、メモを残しておきます。
VagrantのBase Box作成を自動化するVeeweeというツールもありますが、
使ってみてうまくいかなかったので、今回は自分で作ります…。
今回試した環境はこんな感じ。
| OS(Mac) | 10.8.2 |
| Virtual Box | 4.2.6 |
| Vagrant | 1.0.5 |
※Virtual BoxとかVagrantのインストールなどは、今回省略します。
VMは、CentOS6.3 x86_64です。
Virtual BoxのVM作成
まず、Virtual BoxのVMを作ります。
VMは下記のような感じで作りました。
| Name: | vagrant-centos6.3 | |
| Type: | Linux | |
| Version: | Red Hat (64bit) | |
| Memory size: | 512MB | |
| Hard drive: | 8GB (新規作成) | |
| Hard drive file type: | VDI, Dynamically allocated (動的割り当て) | |
| Audio: | Disable | |
| USB controller: | Disable | |
| Port Forwarding: | Name: ssh, Protocol: TCP, Host Port: 2222, Guest Port: 22 |
起動させてOSをインストールします。
メモリが512MBしかないので、テキストモードのインストーラが起動します。(1GB以上だとGUIモード)
キーボード、言語環境を選択します。
テキストモードだと、パッケージ選択やパーティション設定などが設定できないので、
そのまま進めていけばインストーラが終わります。
VMの初期設定
次にいろいろとVMに初期設定を入れていきます。
ネットワークの有効化
そのままだとネットワークが有効になっていなかったので、有効にします。
# /bin/sed -i 's/ONBOOT="no"/ONBOOT="yes"/g' /etc/sysconfig/network-scripts/ifcfg-eth0 # /etc/init.d/networking restart
vagrantユーザの作成
sshで接続するために、vagrantユーザを作成します。
# /bin/sed -i 's/#PubkeyAuthentication yes/PubkeyAuthentication no/g' /etc/ssh/sshd_config # /etc/init.d/sshd reload # /usr/bin/yum -y install sudo # /usr/sbin/groupadd vagrant # /usr/sbin/useradd vagrant -g vagrant -G wheel # echo "vagrant"|passwd --stdin vagrant # echo "vagrant ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
ssh 接続
ポートフォワーディング機能で、ホスト側の2222ポートをゲストの22ポートに割り当ててるので、
localhostの2222にsshします。
$ ssh localhost -l vagrant -p 2222 $ su - # id
必要なパッケージのインストール
いろいろ入れます。
# yum -y install gcc make gcc-c++ ruby kernel-devel-`uname -r` zlib-devel openssl-devel readline-devel sqlite-devel perl
epelのリポジトリ設定ファイルを作成します。
# cat > /etc/yum.repos.d/epel.repo << EOM [epel] name=epel baseurl=http://download.fedoraproject.org/pub/epel/6/\$basearch enabled=1 gpgcheck=0 EOM
ruby-develとrubygemsをインストールします。
# yum -y install ruby-devel rubygems # yum -y clean all # rm -f /etc/yum.repos.d/epel.repo
chefクライアントのインストール
chefをインストールします。少し時間がかかるので、待ちます。
# gem install --no-ri --no-rdoc chef
vagrantユーザの公開鍵配置
vagrantユーザ用の公開鍵を配置します。
# mkdir /home/vagrant/.ssh # chmod 700 /home/vagrant/.ssh # cd /home/vagrant/.ssh # curl -L -o authorized_keys https://raw.github.com/mitchellh/vagrant/master/keys/vagrant.pub # chown -R vagrant /home/vagrant/.ssh
VirtualBox Guest Additionsのインストール
VitualBoxゲストOS用ドライバVirtualBox Guest Additionsをインストールします。
# cd /tmp # curl -L -o VBoxGuestAdditions_4.2.6.iso http://download.virtualbox.org/virtualbox/4.2.6/VBoxGuestAdditions_4.2.6.iso # mount -o loop VBoxGuestAdditions_4.2.6.iso /mnt # sh /mnt/VBoxLinuxAdditions.run # umount /mnt # rm VBoxGuestAdditions_4.2.6.iso
他
# sed -i "s/^.*requiretty/#Defaults requiretty/" /etc/sudoers # sed -i "s/^#UseDNS yes/UseDNS no/g" /etc/ssh/sshd_config # dd if=/dev/zero of=/tmp/clean || rm /tmp/clean
Base Boxのパッケージ化
作ったVMをBase Boxにします。
$ vagrant package --base vagrant-centos6.3
カレントディレクトリにpackage.boxというファイルができます。
あとは、Base Boxをvagrantに登録して、起動させます。
$ vagrant box add my_box package.box $ mkdir test_environment $ cd test_environment $ vagrant init my_box $ vagrant up $ vagrant ssh
以上。
…と、まぁ、ほとんどveeweeの設定ファイルをなめただけなんですが、
とりあえず、流れが把握できたのとchefだけのBase Boxができたので、めでたしめでたし。
veeweeで失敗していたのは、ネットワーク周りが原因な気がする…。
まー、あとは、chefのcookbook作っていろいろ遊んでみよう。
Opscode Chef のトレーニングに参加してきた。
久々のblog更新。
日本Chef User会のFacebookで紹介されている
Chefのハンズオントレーニングイベントに参加してきました。
Japan Chef Users Group | Facebook
トレーニングの講師は、Opscode社のSean OMeara 氏。
全部英語でしたが、（たぶん）普段普通に話すよりゆっくり話てくれてたのと、
周りのスタッフの方々が通訳してくださって、内容は大体把握できました。
ただ、やっぱり質問は流暢な英語でしたかった(´・ω・`)
また、対象者がChefをさわった事がある方 （初級の上〜中級の下）でしたが、
なぜConfiguration Managementが必要なのか、なぜChefなのかとか、
割りと基本的な話を最初にしてくれて内容整理できてよかったです。
以下、自分が気になったところのまとめです。
cookbookのテストについて
Chef のテストについては、３つ。テストの種類によってツールを使い分ける。
1. unit test -> chef-minitest-hundler
calavera/minitest-chef-handler · GitHub
テストできるところとできないところがるので、使い方を工夫する。
2. integration test -> test-kitchin with vagrant
test-kitchen | RubyGems.org | your community gem host
chefはやっぱりvagrantとの相性がいい。開発環境やテスト環境としてvagrantとchefを組み合わせて使う。
これ使ったことがないので、今度試してみよう。
3. Behavior Test -> cucumber chef
Cucumber-chef
cucumber自体全然使ったことがないので、これも今度試す。
個人的にchefのcookbookを書いていて、テストコードどう書くのか、
ものすごーく気になってたところなんですが、
Seanが言ってたけど（たぶん）、
- chefのテストにはカバーできない部分がある。
- UnitTestの中でChefのResource機能の動作をテストするのは無駄。
- why-run機能を使いなよ。
テストに関してだったり、cookbookの使い方だったり、
まだベストプラクティスっていうのはなくて、
会社ごとにポリシーとかもあるし、各自で試行錯誤するしかないっていうのが、
印象でした。
why-run機能について
ver10.14でリリースされた機能。
chefを実行したときの処理をサーバ側に反映せずに動作確認できる機能です。
この機能はchefの開発が始まった頃からチケットがあって、
何度もclose, reopenを繰り返し、議論されてきたらしい。
元々は、dry-runっていうネーミングで作ってたんだけど、今はwhy-run。
dry-runだと、実行中でシステムに変更を加えない
（ファイルを作成したり、マウントをしたりしない）ので、
real-runを実行したときと差分がでてしまう。
why-runは、実行中にシステムの内容が変わるところもカバーしている。
chef実行時のフォーマットについて
chef-client実行時に、Fオプションで出力結果を変更することができる。
$ sudo chef-client -Fdoc -lfatal --color --why-run
null, doc, minimal, minの４つが現状使用可能。
その他、開発に便利なツールについて
bento
opscode/bento · GitHub
vagrant用baseboxの作成を効率化するツールveeweeをカプセル化するもの。
test-kichin
Integration Test Tool
opscode/test-kitchen · GitHub
foodcritic
link checker, style guide
Foodcritic - A lint tool for your Opscode Chef cookbooks
これはめちゃくちゃ参考になる！色々と間違ってcookbook書いてた。
設定ファイルに設定を追加するためには
rubyで書く場合
Class: Chef::Util::FileEdit
— Documentation for chef (0.8.16)
上記クラスをruby blockの中で使う。
bashで書く場合
bushスクリプトを書いてexecuteで使う。
Chef の処理系について
- chef-client実行
- build node
- authenticate
- sync cookbooks(expanded run list)
- load cookbooks
- converge
- success?
- if yes -> run
- if no -> error
chefのresourceとLWRP
chefのcookbookは、Lightweight Resources and Providers (LWRP)という機能を使うことによって、
recipe内で使うresourceを簡単に定義することができます。
用意するファイルは下記になります。
resources
resourceで使うactionとattributeの定義とバリデーションをLWRPの形式で記述する。
providers
resourceの具体的なアクションを記述する。中でchefで定義しているresourceを使うことができる。
SaltStackを試してみた
SaltStackは、大量のサーバを管理運用するためのリモート制御・設定管理ツールです。
capistranoなどのリモート制御ツールとpuppet, chefなどの設定管理ツールを合わせたようなものという印象です。
pythonで書かれてます。
インストール
まずは、インストールから。saltstackは、以下のものに依存があります。
Python 2.6
ZeroMQ >= 2.1.9
pyzmq >= 2.1.9 - ZeroMQ Python bindings
M2Crypto - Python OpenSSL wrapper
PyCrypto - The Python cryptography toolkit
msgpack-python - High-performance message interchange format
YAML - Python YAML bindings
では、CentOSに、saltstackを入れてみましょう。上記の依存ツールはyumでいれるとまるっと入れてくれます。きっと。
# wget -O /etc/yum.repos.d/epel-salt.repo \\
http://repos.fedorapeople.org/repos/herlo/salt/epel-salt.repo
SaltStackは、サーバ/クライアント型のツールで、サーバとクライアントは、それぞれmasterとminionと呼ばれます。
master、minionをインストールします。
#yum install salt-master
#yum install salt-minion
設定
設定ファイルはそれぞれ下記になります。
/etc/salt/master
/etc/salt/minion
# vi /etc/salt/minion - #master: salt + master: 10.0.0.1
実行
master側
# salt-master -d
minion側
# salt-minion -d
master側で、アクセスを許可するminionサーバを設定する。
# salt-key -L # salt-key -A or # salt-key -a <minion's id>
今日はとりあえず、ここまで。
Linuxサーバ構築ツールまとめ
仮想化技術が進歩し、大量のサーバを管理・構築することが多くなりました。
PuppetやChefなど、サーバ構築・管理を自動化するいろんなツールがあるので、
整理しておこうと思います。
以下の３つに分類します。
- Provisioning Tools
- kickstart
- cobbler
- crowbar
- spacewalk
BIOS設定、PXEブート、kicskstartなど、一番下のレイヤーのOSインストールまでを行うツールです。
- Configuration Management Tools
- puppet
- chef
- saltstack
- rundeck
and more...
http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software
パッケージ管理や設定ファイルの配布など、OSより上のレイヤーの管理を行うツールです。
- Orchestration Tools
- capistrano
- fabric
デプロイや設定ファイルの修正など、大量のサーバに対しインタラクティブな操作を行うツールです。
以下、リンクとメモ書きです。
Provisioning Tools
kickstart
RHEL系のLinuxディストリビューションのOSインストールを自動化する機能。
http://fedoraproject.org/wiki/Anaconda/Kickstart
cobbler
Linuxの自動インストールを管理するサーバ。
http://cobbler.github.com/
crowbar
サーバプロビジョニングのプラットフォーム。ファームウェアのUPDATEやPXEブートからのOSインストールが可能。
DELLのCloudEdge Solutions Teamが、OpenStack用のインストーラとして開発したもの。
Chefサーバをラップしているので、OSから上の設定をできるのかも。
https://github.com/dellcloudedge/crowbar/wiki
spacewalk
サーバのHW設定の情報を閲覧したり、kickstartを実行したり、ブラウザからサーバの管理ができる。RHEL系のみ。
http://spacewalk.redhat.com/
Configuration Management Tools
puppet
システム自動管理ツール。rubyで書かれている。サーバ/クライアント型。
サーバ側でマニュフェストと呼ばれる設定ファイルを管理し、
クライアント側は定期的に(デフォルトで３０分)サーバからマニュフェストを取得し、
クライアントサーバをあるべき姿に維持する。
http://puppetlabs.com/
