クラウド上でのChef活用と ベストプラクティス v0.2.0

クラウド上でのChef活用とベストプラクティス2013年7月23日　ニフティクラウド meet-up！

#ncmeetup

ソリューション事業部　第一開発部

株式会社エスキュービズム

赤間　慧 Satoshi Akama

自己紹介

タブレットPOS

ECサイト構築

たまにiPadアプリ開発

サーバサイド開発

サーバ構築・管理

company me

最近はフルスタックエンジニアに片足突っ込んでいます

基本的にdev側の人間です

Chef

CMS開発

Cassandraベースの解析ツール

サーバ構築・管理

etc

赤間　慧 Satoshi Akama

https://github.com/sakama

“Chefの基本”

“弊社での実際のシステム構築時のChef活用方法”

“Chefのベストプラクティス”

service do

end

action [:enable, :start]

service do

end

action [:enable, :start]

“今後Chefサーバ等の運用で実現したいこと”service do

end

action [:enable, :start]

service do

end

action [:enable, :start]

本日のrecipe

Chefの基本

ChefとはConfiguration Management Frameworkサーバセットアップの自動化を実現するためのFramework

IaaSOpenStack

PuppetChef

CapistranoFabric

クラウド or VM立ち上げ

OSインストール

System Configuration<OSやミドルウェアの設定・構成管理>

2013.07.14開催July Tech Festa 2013でのGosuke Miyashitaさんの資料で紹介されていた「Provisioning Tool chain by Lee Thompson at Velocity 2010」による日本語訳の責は私にあります。直訳だと全て「設定」「管理」のようになるので翻訳が難しい

http://www.slideshare.net/mizzy/serverspec-jtf2013

Application ServiceOrchestration<デプロイ等>

Bootstrapping<初期セットアップ>

Configuration

Orchestration

Chefとは 2

RubyのDSLで記述

package "apache2" do action :installend

Infrastructure as Codeサーバ構築手順書を元にした手動セットアップ

スクリプトやファイルの記述を元にセットアップを行う = プログラマブルなInfrastructure

= 特定のタスク向けに設計された言語DSL(Domain-Specific Language)

汎用プログラミング言語= C、Java...etc

汎用モデリング言語= UML...etc

Chefの最大の特徴

冪等性べき とう せい

ある操作を1回行っても複数回行っても結果が同じであることをいう概念

がChefによってある程度担保される(使用するResource、recipeの記述による)

Chefの動作の仕組み

cookbooksApache cookbook

Postfix cookbook

recipesRuby cookbook

cookbookを元にChefが自動でサーバを設定する

サーバ群

recipes

recipes

Chef Family 1

Hosted Chef

Private Chef

Opscodeがホスティングする

Firewall内で稼働する

http://www.opscode.com/hosted-chef/

この2つは国内で採用した話を聞きませんが...

Facebook等で採用事例

私も詳しくは知りませんm(_ _)m

Chef Family 2

Chef Server/Client(管理対象数十台over)

Chef Solo(管理対象数台～頑張れば数十台)

Chef ServerとChef ClientからなるClient/Serverモデル

Chefを単体で動作させるもの。最初はこちらで十分Chef Serverを使っているようなケースでもテスト中はこちらを使ったり

Chef Server / Chef Server Web UI / Couch DB / Rabbit MQ / Chef Solr

構成要素がかなりFat

インストールは最近は楽ネットで検索するとChef Severのインストール難しいというようなブログが数多く出てきますが、最近はインストーラで一発です

ただし、運用はまた別の話

実質この2択になるのでは？

＋

＋

＋

情報がChef Server 10.xのもので古かったです懇親会でご指摘を頂いたのですがChef Server 11.xはコアエンジンがRubyからErlangに、Couch DBからPostgreSQLになっているそうです。手元で試したらフロントもnginxになっていた...

omnibus インストーラ

omnibusインストーラOpscodeより提供されているインストーラ。Chef Serverからの実行時等様々な場所で使われていますOS/ディストリビューションを判断してChefをインストール。独自パスでRubyも入るのでこれだけでChefを使う準備が整う

curl -k -L https://www.opscode.com/chef/install.sh | bash

Rubyの実行パス→/opt/chef/embedded/bin/rubygemのインストール→/opt/以下になる

逆に言うとアプリでRubyが必要な場合等は別途インストールが必要

システムを汚しにくい※Chef関連のコマンドが/usr/bin/以下にシンボリックリンクとして貼られる

cookbookChefでセットアップを行うための設定のまとまり。ミドルウェア単位が多い

cookbooksattributes

definitions

files

recipes

属性を管理例) ApacheのMaxClientsの値

レシピで使う共通関数等

サーバ上に配置したいファイル等例) git cloneする際のデプロイキー

Cookbookの動作を決める一番よく触る部分

Apache cookbook

Postfix cookbook

recipesRuby cookbook

recipes

recipes

templateserb形式のテンプレートファイル。値をassignして使用する例) httpd.conf.erb

Recipe

様々なResourceが各種処理を担当する

templatedirectoryservice

Resource

package "apache2" do action :installend

package

Resourceや記述によっては冪等性が損なわれる

パッケージのインストール、アップグレードなど

erb形式のテンプレートを元にファイルを設置ディレクトリを設定サービスの管理/起動

script、executeリソースはChefのDSLの制約を受けずに何でもかけるが、冪等性が損なわれる恐れがあるので多用は良くないと言われる

Chefの周辺ツール knife

Chef Server/Chef Client使用時

Chef Solo使用時

Chefに付属するコマンドラインツール

knife-*knifeのプラグイン。上のknife-soloの他、knifeコマンドでIaaS制御できるものなどがある

knife-soloというものがありますChef Soloは基本的に対象サーバ上でchef-soloコマンドを実行するが、リモートサーバのprovisioningが実行できる

knife client create Clientの作成

knife cookbook upload Chef Serverへcookbookをアップロード

knife ssh 複数のサーバで同時にコマンドを実行

多用すると思います

Chefの周辺ツール VagrantVirtualBox等のVMをコマンドラインから立ち上げるツール。Chef界隈での利用率高し

基本コンポーネントBox

利用方法

マシン起動やprovisioning実行したりするコマンドツール群VagrantfileVagrantコマンドライン

(仮想)マシンを作成する際のテンプレートとなるBoxを元にマシンを立ち上げる際の設定を記述

# Boxを追加$ vagrant box add base http://files.vagrantup.com/lucid32.box# Vagrantfileの作成$ vagrant init# マシンの起動$ vagrant up

ここ最近の「IT系難読単語」化してますが、開発者のMitchel Hashimotoさんが「アイ メイク ヴェイグラント」と仰ってますhttp://www.youtube.com/watch?v=vk7hHhhIt10

Vagrantのコマンド

vagrant up

vagrant provision

vagrant halt

vagrant destroy

VM起動、VMのprovisioningを実行

ChefやPuppetによるVMのprovisioningを実行

VMの停止

VMの破棄

vagrant ssh 起動したVMにSSH接続

コマンド一覧

Vagrant.configure("2") do |config| config.vm.provision :shel l , : inl ine => "echo Hel lo" config.vm.define :web do |web| web.vm.box = "apache" end config.vm.define :db do |db| db.vm.box = "mysql". . .

Multi Machine機能 Vagrantfileの記述を変えると1回のvagrant upで複数VM立ち上げ可能

Vagrant Plugin

SaharaVMの状態を記録して後でその時点にロールバックできる

vagrant plugin installコマンドを使いますが、実体はrubygemsから取得様々なpluginが公開されています

vagrant plugin install <name> プラグインのインストールvagrant plugin list インストールされているプラグインの一覧表示

vagrant sandbox on sandboxモードをonにする

vagrant plugin install sahara

＋ コマンド

vagrant sandbox rollback 変更を元に戻す

vagrant sandbox commit 変更を反映する

vagrant sandbox off sandboxモードをoffにする

IaaS等にも対応Vagrant1.1からはIaaS上のサーバをVagrant経由で起動することも可能gem経由ではなくパッケージでの提供に変更になっている (dmg、exe、rpm等） ので旧バージョン使っている方や昔の雑誌・ブログ等を参照する場合要注意

VirtualBoxVMWare FusionAWSRackspace

対応状況標準対応標準対応vagrant-awsプラグインで対応vagrant-rackspaceプラグインで対応

Vagrant本あるよ

Vagrant: Up and Running

今のところ英語版だけですが、日本語版出すことが2013/7/12のvagrant meetup後に決まったようです。

英語版でも150ページ弱、7章のプラグイン開発とか読まないなら100ページほどです。

Create and Manage Virtualized Development Environments

By Mitchell Hashimoto

Vagrantからのニフティクラウド利用

...私はあります

ところでニフティクラウドユーザなそこのあなた、こう思ったことはありませんか？

Vagrantからニフティクラウド上のサーバ立ちあげたい...

vagrant-niftycloud ないの？

Vagrantからのニフティクラウド利用

...私はあります

\ 作ってみた /

ところでニフティクラウドユーザなそこのあなた、こう思ったことはありませんか？

Vagrantからニフティクラウド上のサーバ立ちあげたい...

vagrant-niftycloud ないの？

vagrant-niftycloud（開発版）ニフティクラウド上のサーバ立ち上げ、provisioning実行するためのVagrant plugin

・rsyncを使ったファイル転送・VagrantがSSH接続してコマンド実行可能な状態にする

Chef以外も動作Puppet / Ansible(Vagrant1.2.0+) / CFEngine (Vagrant1.2.0+)

$ vagrant plugin install vagrant-niftycloud

Chef以外はまだテストしていないが、pluginでやっていることは

だけなのでVagrantでサポートしているものは動く気がする...

vagrant-niftycloud　コマンド

vagrant up --provider=niftycloud

vagrant provision

vagrant halt/suspend

vagrant resume

サーバ立ち上げ、サーバのprovisioningを実行

Chef等によりサーバのprovisioningを実行

サーバの停止

停止したサーバの起動

vagrant ssh 起動したサーバにSSH接続を実行

vagrant destroy サーバの破棄

用意しているコマンド ※Vagrantのnetwork機能については非対応

ローカルのVirtualBoxやVMWare Fusionではダメ？

Develop Locally.Test Remotely.

今までもリモートサーバ上でchef-soloを叩いたり、ローカルマシン上でknife-soloを使ってリモートサーバのセットアップを行うことはできた

実際に使うRemote環境でテストが簡単に行える

http://www.youtube.com/watch?v=vk7hHhhIt10

by Mitchel Hashimoto

providerは適材適所で使い分けましょう。VirtualBoxもproviderの一つに過ぎない

Vagrantを使うとより簡単にリモートサーバ上でのテストができる

vagrant-niftycloud　利用想定シーン利用想定シーン

サーバが立ち上がるのはローカルマシン上のVirtualBox等より遅いがprovisioningは速い本番環境にニフティクラウドを使用している場合、本番と同じ環境でテストできる

Chef cookbookやPuppetのマニフェストの開発を行いたい場合

オススメしない例

CIを行う際のJenkins等からの利用Jenkinsサーバ上のVM立ち上げるよりサーバリソースを食わない（弊社事例紹介で後述)

本番環境構築　→vagrantユーザがいたりするのでおすすめしません。あくまでテスト環境構築を想定しています。

サーバのprovisioningを行わない場合(単純にコマンドラインからサーバ立ちあげたい)　→ニフティクラウドのCLIやSDK使うほうがいいと思います　　vagrant up --provider=niftycloud --no-provision である程度可能　　(rsyncによるローカルファイルの同期までは走る)

＋

＋

＋

手元のVM向けboxと同じ名前でニフティクラウド用のbox追加しておけば、普段はローカルでvagrant up、ニフティクラウドで動くか試す時はprovider指定してvagrant upとか

vagrant-niftycloud 制約

・vagrantユーザがパスワード無しでsudoできる必要がある・sudoがttyなしで実行できる必要がある・SSH秘密鍵はパスフレーズが空である必要がある・場合によってはchef-client/chef-soloのインストールが必要

通常のVagrant使用時と同様に

各自プライベートイメージを作成して使用する必要があります m(__)mニフティクラウド公式のOSイメージそのままは使えません

vagrant-niftycloud 協力依頼バグ報告、pull requestなどお待ちしています

https://github.com/sakama/vagrant-niftycloud

トラックナンバーが足りません！

Configuration Management Framework周辺のテスト事情

Chef以外のもの、Chefと関係なく独立して動作するものも含みます

シンタックスチェック

ユニットテストと呼ばれているもの

結合テストと呼ばれているもの

Chef Specrspec-puppet

Minitest Chef HandlerCucumber ChefTest Kitchenrspec-systemserverspec

Foodcriticknife cookbook testpuppet lint

構築済みのサーバに対するテスト

Report Handler / Exception Handler使い方によってはいろいろできると思います

実はよく目にしているかもしれない

handlerを作成するとChefで実行された内容等が取得可能

・実行完了時にメール通知・実行完了時にIRCに通知する・実行時のログをIaaSのディスクにアップロードする

http://docs.opscode.com/essentials_handlers.html

[2013-07-18T08:54:47+00:00] INFO: Chef Run complete in 37.044959889 seconds[2013-07-18T08:54:47+00:00] INFO: Running report handlers[2013-07-18T08:54:47+00:00] INFO: Report handlers complete

Chef Solo実行完了時に表示されるアレです

様々なhandlerが公開されています

Report HandlerException Handler

Chef実行完了時に特定動作を起動するChef実行失敗時に特定動作を起動する

ドキュメントを読んでいて魔が差した

ちょっとしたサーバ仕様書ぐらいだったら出力できるんじゃない？

Report Handler / Exception Handler

サーバ仕様書書くの意外と大変ですよね？

ドキュメントを読んでいて魔が差した

ちょっとしたサーバ仕様書ぐらいだったら出力できるんじゃない？

\ 作ってみた /

Report Handler / Exception Handler

chef-handler-pdf（3割程度ネタです）

サーバ仕様書がPDFで出力できます・実装方法がいくつかあるようですが、cookbookとして実装・Chefの初回実行時しか機能しません...・全部はpushしてないので、気が向いたらUPします

・サーバの基本情報はOhaiから取得・実行されたresourceの内容はReport Handler経由で取得

https://github.com/sakama/chef-handler-pdf

弊社での実際のシステム構築時のChef活用方法

利用範囲

ニフティクラウド専用サーバVPS等

全体では数十台程度のサーバをChefを使って構築している

｛

｛

テスト環境構築

各開発者の開発環境構築

小売店舗向け端末APIサーバ

ECサイト 飲食店向け端末APIサーバ本番環境構築

Chef利用についてOpscodeコミュニティcookbookをベースにしている元々が個人的にサーバセットアップを自動化したくて始めたものが公式プロジェクト化

公開されているcookbookを使うだけでも「それなりに」動くので、エンジニアの皆さんなら「作りました」メソッド使えばいいのでは...(私見)

サーバは構成が多岐に渡るのでロールで複数構成対応

基本的には全開発者が利用者・Chefに詳しい人間ばかりではない・Objective-C等の開発のみをやっている開発者が開発環境構築で使うこと　等も考慮する必要がある

web、db、app等

改善できた点クオリティの統一基本Appエンジニアしかおらずサーバ構築スキルに差があったがクオリティの統一

サーバ提供の迅速化

開発環境構築の手間が減った

・新しく入社したメンバーやクライアントサイドの開発をしていて、　サーバサイドに詳しくないメンバーでも開発環境構築が楽にできる・全員が共通の環境構築が可能(“ちょっと違う”環境はchefのattributeで対応可能)

以前はVMイメージ配布→数GB単位のイメージファイルのネットワーク経由での配布は時間が掛かる

サーバ構築依頼からセットアップ完了までの迅速化

Chef Server

導入は進めていますが、まだ利用していません

使えるところと使えないところがある

通常の受注案件

・保守契約の絡み・他社も作業を行う場合がある

使用不可

SaaS型での提供もやっていまして...

全て自社で管理

使用可

node.jsベースの管理画面までは作ってあるが、マンパワーが...

Chef cookbookの開発

ローカルでVagrant＋VirtualBoxで開発vagrant upでサーバ立ち上げ＋provisioning実行以後vagrant provisionを繰り返す

$ vagrant up VM already created. Booting if it's not already running... Clearing any previously set forwarded ports... Forwarding ports... -- 22 => 2222 (adapter 1) Creating shared folders metadata... Clearing any previously set network interfaces... Running any VM customizations... Booting VM... Waiting for VM to boot. This can take a few minutes.

実際のサーバのセットアップ

http://www.engineyard.co.jp/blog/2013/chef-tutorial-updated/

https://speakerdeck.com/naoya/vagrant-plus-chef

実際のサーバのセットアップ 2そのやり方でやっています(申し訳ございません)

(1) settings.jsonにサーバ設定内容を記述して下さい(2) install.shをキックして下さい

全員にRubyの実行環境構築強制かつknife soloコマンド叩くの強制するのは時期尚早でそれよりはChefの効果を実感してもらって広めるのが先と判断

# omnibusインストーラでChefをインストールcurl -k -L https://www.opscode.com/chef/install.sh | bash

# chef-soloコマンド実行chef-solo -c ./solo.rb -j ./conf/settings.json

install.shの内容

というよりchef-soloコマンドすら叩かせてないです

使いたい人はknife solo使ってという形にしています

Chef cookbookのCI社内サーバでJenkins＋Vagrant＋VirtualBox

Jenkinsサーバ

VirtualBox

Vagrant

cookbookをホストしている社内Gitサーバ

master

developgit pull

Cent OS6.x Cent OS 5.x

vagrant up

Chef cookbookのCI 2

Gitのmaster、developのcookbookに対して1日各2回通常のソフトウェアのテストの場合、Jenkinsの「SCMをポーリング」を使用してレポジトリにgit push(svn commit)されたらビルド実行が多いが、・同時に同一のVagrantfileを使って複数のVM立ちあげられないので　複数ビルドを並列実行できない(Multi VM機能という意味ではなく)・複数ビルドが同時に走るとメモリ食う・1回のテストに1h弱掛かるのでビルドのキュー待ちが凄いことになりそう以上の理由により 定時実行

構築済みサーバのテストは行えていないserverspec等利用してテストできるところまでできればいいが、現状recipe適用時にexit 1吐かないかどうかを確認しているレベル

Chef cookbookのCI 3JenkinsでBuild Pipelineを組んでいるJenkinsのBuild Pipelineプラグインを使用しカスタムビューを作成

webdbapp

webロールのみ dbロールのみ その他のロール

Chef cookbookのCI 4Build Pipeline継続インテグレーションのプラクティスの１つで、テスト等を複数のステップに分割し、順番に流していく

一般的なアプリケーションのBuild Pipeline

cookbookのCIのためのBuild Pipeline

SCMへのコミットをトリガー

結合テスト サーバへデプロイ

ユニットテストが(成功したら|失敗しても)実行 (手動|自動)で実行

ロール1でテスト

ロール2でテスト

ロール3でテスト

定時実行 ロール1のテストが(成功したら|失敗しても)実行

ロール2のテストが(成功したら|失敗しても)実行

＋

＋

ユニットテスト

Chef cookbookのCI 5

定期的なテストはやった方がよい・(rpm|deb)パッケージのダウンロードURLが変わった・アプリ側の修正でデプロイの部分が動かなくなった

1回のテストで1時間弱かかるので手動は無理・時間掛かるテストは機械に任せましょう

この方法はやめたいテストがコード変更以外の理由で失敗することが多いなぜかApacheの起動に失敗したり→Jenkinsからのアラートメール多発で狼少年状態に

メモリ食う8GBメモリ搭載のサーバ使ってもvagrantのMulti Machine機能使用して同時にVM2つが限界

VirtualBoxがちょっと不安定...?・i386のboxは追加できてもx86_64のboxが追加できないことがあった・vagrant destroy -fに失敗することが多発→VMの残骸が残ってDisk Full　CUIのみのホストOSだと設定が面倒なのでGUI使えるホストOSが良い

今後Chefサーバ等の運用で実現したいこと

新CI環境　構想IaaS上でテストする

Jenkinsサーバ

Vagrant

cookbookをホストしている社内Gitサーバ

master

developgit pull

Cent OS6.x Cent OS 5.x

vagrant up

IaaS

テストの並列実行が可能に今まではJenkinsサーバのスペックの制約で1つずつ実行

ロール1でテスト

ロール2でテスト

ロール3でテスト

並列実行でテスト実行時間を短縮

ロール4でテスト

ロール1でテスト

ロール2でテスト

ロール3でテスト

ロール4でテスト

30分以上短縮サーバ利用料節約のため、

ここでFailした場合以降は実行しない

構築済みサーバのテスト

serverspecを入れたい

・記述が容易(RSpecベース)・Chefを使用せずに構築したサーバのテストも行える・SSHさえ繋がればテストできる

マンパワー不足により手を付けていなかったがもっと早く取り入れていても良かった

IaaSとの連携AWSでいうOpsworksが広く実装されればサーバセットアップ〜提供まで楽になる

本番環境一歩手前のテスト環境としての利用

http://www.youtube.com/watch?v=vk7hHhhIt10

VagrantのMulti Provider機能を利用して・ローカルVM環境・リモートテスト環境　を適宜切り替えて利用

ニフティクラウドの場合Cloud Automation βが6/4に公開された

(1) 設定用JSONから漂う芳醇なChefの香り

{ "run_list": [ "recipe[nc::dependency_resolver]", "recipe[nc::manager_store]", "recipe[nc::manager]" ], "nc": {

(2) 中でもChef使ってるみたいです...よ？

Chefのベストプラクティス

アプリのデプロイは別に考えるアプリのデプロイはCapistrano等使う方が良いかも

Chef使ってアプリのデプロイまで行うと、アプリ改修の余波を食らってデプロイ失敗するというのを食らったことが

IaaSのオートスケーリング使う場合、Chefで都度構築していると間に合わない

Dev、Opsが明確に分かれている場合ちょうど線引きできる？（作業的な意味で)サーバセットアップまではやるので、以後デプロイからはよろしく...とか。

subversionリソースはsvnサーバがhttps&自己署名(オレオレ)証明書だと動作しませんでした

ミドルウェア設定まで完了済みのイメージからインスタンス起動&アプリのみデプロイツールでデプロイ

＋

＋

＋

Chef Serverだけがあればいいというわけではない・cookbookの開発環境・運用態勢・メンバーのスキル・CI環境

無理にChef Server使う必要はなさそう

身の丈にあったツールを使えばいいんでは

どうせならChef Server入れるぜ！という気持ちは分かりますが

日々改善

END