MySQL Casual Talks vol.7に行ってきた

今回は後輩エンジニアである @hfm ことおっくんの社外勉強会登壇デビュー戦を応援に行くのが1つ大きな目的。

当日の様子はtogetterから伺えます。肝心の彼の発表ですが、TLから拾う限り

  • やばい話キタ
  • タイトル
    • 地獄感
    • 既につらい
    • 地雷臭
  • 4.0ハラスメント
  • 怖すぎる
  • ガチュアル
  • ただただ、すごい

と参加されていた皆様を恐怖のドン底に陥れるには十分な内容だったと感じます。スライドはこちら

では実際はどんな感じで進めていたかというところで、スライドの最後やおっくんの後日エントリに先輩エンジニアへの謝辞はありましたが、手助け出来たのはほんの少しで、ほぼ一人で頑張ったというのが合っているかなあと思います。

検証や当日の手順などメンテ完遂までに試行錯誤した記録として、Issueはマイルストン内に大小ありつつも34 issues、1つのIssueに133コメントがついたものもありました、すごい。他にもこの1年色々な実績はあるんだけれど、このタスクに関してはホントによく頑張った。

おまけで後日談。

メンテを終えて2日後、いきなりおっくんが銀髪になって現れたのにはビックリして、志村けんばりに二度見したのも良い思い出。

登壇された皆様、主催いつもありがとうございます @myfinder、お疲れさまでした。

Vagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術

Pepabo AdventCalendar 2014の10日目の記事です。昨日はあんちぽサンタ記事を見て入社したlaughkでした。明日はhisaichi5518です。

ソフトウェアのビルド方法について。

  • 今年は特にセキュリティ関連でCVE対応が多かったり
  • 経年したサービスのOSは刷新したいけど同じミドルウェアのバージョンを使いたかったり

な時に、rpmをビルドするのはしんどい(弊社は主にRHELクローンなディストリを使っています)ということで、今年は社内でVagrantを利用した、ビルド済ソフトウェアのtarボールを作るのが流行りました。

今日はその一例としてApacheのビルドについて。サンプルのプロジェクトを tnmt/vagrant-build-apache22に置きました。

git clone https://github.com/tnmt/vagrant-build-apache22
vagrant up cent6_build_apache22
vagrant up cent7_build_apache22

するだけで、CentOS6, CentOS7用のApache 2.2のビルド済tarボールが出来て、vagrant up したカレントディレクトリに配置されます。

ディレクトリ配置は

├── Vagrantfile -> vagrant/Vagrantfile
└── vagrant
    ├── Vagrantfile
    ├── build-apache2.2.sh
    └── install-facter.sh

で、スクリプトは

の2つです。今回はVagrantのVirtualBoxのイメージにhfmvagrantcloudのイメージを使っています。Vagrantfileに記載されている hfm4/centos6, hfm4/centos7がそれぞれそうですね。ビルド済みのtarボールは各OSに配置して展開するだけですぐ使えます、お手軽。

以降は何故この方法をとったかと、工夫しているについて。

何故シェルスクリプトか

大きくは2つ

  • ちょっとした修正を加えやすいようにしたい
  • OSのバージョンが変わってもそのまま同じスクリプトを利用したい

というところでしょうか。もしこれがrpmをビルドしようとするとspecファイルで差異を吸収することになりますが、シェルスクリプトの方が読み書きに慣れている人が多いのでメンテしやすさでもメリットがありました。スクリプトの内容自体はなるべく実際にビルドする手順を再現するだけのシンプルに保つように心がけています。

また、ソースの取得もシェルスクリプト内で行っているのでビルドに必要な環境(今回のサンプルにあるようなgitリポジトリ)はVagrantfileとスクリプトだけで良く、管理が楽というのもあります。1枚のスクリプトにしておくと取り回しも便利です。

Apacheの場合もパッチの追加やモジュールを同時ビルドしたり(サンプルプロジェクトではmod_extract_forwardedも同時にビルドしています)、他サービスに持っていってconfigureオプションを変えたりが簡単に出来ますし、先の例の通りOSのバージョン差も全く気にせずに済んでいるのが分かるかと思います。

facterを使ってる

これは工夫というほどではないですが。

弊社では構成管理ツールにPuppetを利用しており、社内で共用しているベースのVMイメージは既にPuppetがインストールされているため、Facterもインストール済ですが、最小構成のOSインストールイメージにはFacterがインストールされていないため、今回のスクリプトでは build-apache2.2.sh から install-facter.sh を呼び出しています。

さて、そのFacterは何に使っているかですが build-apache2.2.shこちら でOSのバージョンなどの取得に利用しています。シェルでも取れるけどこんな感じで値が取れるという例です。

platform=$(
    arch=$( facter architecture )
    os=$( facter operatingsystem )
    release=$( facter operatingsystemrelease)
    echo ${os}${release%.?}-${arch}
)

スクリプト内ではこれをビルド済みのtarボールの名前のsuffixに利用しています。

実際これをどう運用しているか

先にPuppetを利用していると書きましたが、そのリポジトリにtarボールをコミットしておき

define tarball_deploy (
  $source,
  $dest
) {

  $command = "tar xzf ${name} -C ${dest}"

  file { $name:
    source => $source,
    notify => Exec[$command],
  }

  exec { $command:
    refreshonly => true,
  }

}

のようなdefineを作っておけば

$version = "2.2.29-0"
tarball_deploy {
  "/usr/local/src/apache-${version}.tar.gz":
    source => "puppet:///modules/web/usr/local/src/apache-${version}-${os}.tar.gz",
    dest => '/usr/local';
}

といったマニフェストで展開が可能です(※ ${os}はカスタムファクター)

以上、最近はパッケージと適材適所でこのように素朴にビルドするのを組み合わせて効率化を図っています。素朴にビルドする例としては他にもanybuildを利用したものなどがあります。こちらは@lamanotramaスライドがありますので御覧ください。

はー今年は何だか色々なものをいっぱいビルドしたなー、来年は平和だといいですね…。

Fedora 21へのアップグレード

アップグレード定期報告。

オフィシャルの案内にある通り、Fedora 21からはfedupに--productというオプションが必要。

https://github.com/wgwoods/fedup/blob/master/fedup/commandline.py にもある通り

  • server
  • cloud
  • workstation
  • nonproduct

から選ぶ。以下を実行

sudo fedup-cli --network 21 \
  --product nonproduct \
  --nogpgcheck \
  --debuglog ~/fedup21debug.log

--nogpgcheckは無しだと

setting up repos...
getting boot images...
.treeinfo.signed

Downloading failed: invalid data in .treeinfo: File contains no section headers.
file: /var/cache/system-upgrade/.treeinfo, line: 1
'-----BEGIN PGP SIGNED MESSAGE-----\n'

なエラーで止まってしまった為…良い子はマネしないでね!

シンプルなtd-agent2用systemd Unit設定ファイル

CentOS7用にtd-agent2をインストールした場合の起動スクリプトはどんな感じになるかなと書いてみる。

[Unit]
Description=td-agent is a data collector
After=syslog.target network.target

[Service]
Type=simple
User=td-agent
Group=td-agent
ExecStart=/usr/sbin/td-agent --log /var/log/td-agent/td-agent.log --use-v1-config

[Install]
WantedBy=multi-user.target

これでひとまず起動と停止は普通に出来るけど、旧initスクリプトでやっているulimit設定だったり、reload時のHUPのあて方とかはまだサッパリ分からないのでまだ全然。

それより、CentOS7用にomnibus-td-agentを準備するのが超時間がかかった…もし自分でやるときは、Ruby 2.1が必要なのでrbenv (ruby-build) でインストールしてからビルド。

メンテされてるTreasure Dataの方には頭が上がりませんね。

CentOS7ではPuppet2系が動かない

なぜなら標準で提供されてるパッケージのRubyが2.0以上になっているため。CentOS7はPuppetは3系しか動作しない。

以下、標準・Puppetlabsリポジトリを使ったパッケージによるインストールした場合についてです、gemの場合とかは知らない。色々ごちゃごちゃといじっていたので他のCentOSのバージョンとの整理も兼ねて。

CentOS5, CentOS6はPuppetlabsのyumリポジトリを利用することでPuppet 2系も3系も動く。ただしCentOS5の場合はディストリ標準パッケージのRubyが1.8.5の為、PuppetlabsのdependenciesによってRubyが1.8.7にアップグレードされることに注意。

つまり既存にCentOS5,6混在の環境があって、新たにCentOS7を追加しようとした場合は

  • 早々に既存マニフェストをPuppet 3.X readyにマイグレーションして
  • 既存環境のPuppetも3.Xにアップグレード

していった方が良い。2.Xのサポートもいつまで続くか分からないし。

既存環境にCentOS4があった場合は…サポートも切れてるし知らない子ですね…

マニフェストの互換性は0.2Xから2.6はほぼ問題無いけれども(2.7も大丈夫なはず)、2.Xから3.Xはちょこちょこエラーになる部分もあるんで頑張って直す。

Release Noteをみて変更点だけ直せば大概OKだけれど、他ハマりどころとしては、Puppetと同じタイミングでバージョンアップされるFacter 2.X でObsoluteな記載方法がある為、自作facter変数を修正しないといけないかもしれないというところ。

Facter.add(:servertype) do
    setcode do
 -    Facter.hostname.gsub(/\d+$/ , "")
 +    Facter.value(:hostname).gsub(/\d+$/ , "")
    end
  end