話は、次の流れで進めます。

• 導入の目的
• 「開発会社」との状況の違い
• 自動化されるノウハウとは
• 留意している事
• 今後について
• おわりに

また、本内容は「Chef Casual Talks Vol.1」にて、私がLT時に利用したスライドをもとに、より詳しく記述しております。スライドと合わせてご覧頂くと、概要がつかみやすくなるかと思います。

導入の目的

当初の目的は、新規構築時に用いている「標準作業手順」の自動化でした。ポイントは2つ「同じ手作業を繰り返さない」と「書類ではなくプログラムにまとめる」です。

私たちのようなMSPには、数多あるサーバを運用してきた経験から導かれたノウハウ、即ち「設定の定石」があります。案件が違うとはいえ、途中まで同じ手順を何度も手動でやるのは、時間がもったいないですよね。コマンド一発で、パパッとコーヒーを淹れる間に自動で出来上がっているくらいが嬉しいものです。

そして、手順書ではなく自動化...即ちプログラム化しておけば、仲間全員が常に最新の手順を直ちに利用できます。手順書を基により良い手順を用いて作業をした後、手順書ですとどうしても「後でメンテナンス」となりがちですが、プログラムなら使ったものそのものが残っています。手間が省けて便利です。

ここから、自動化する事で「繰り返しの手動作業が減る」「手間が省ける」のです。ここから、最も目的に適しているツールが Chef でありました。

「開発会社」との状況の違い

Chef をソフトウェア開発会社で導入する場合、多くは新規開発するソフトウェアのCI(Continuous Integration)を実現するためではないでしょうか。当初想定したハードウェア・OS上であれば、どの環境でも等しくシステムを稼働させる事ができるようにし、その場しのぎの開発から脱却できるようにしているはずです。

一方、MSPは「構築・運用手順の自動化」、即ち業務のモデリング・デザインのために利用します。言うなれば、MSP業務のシステム開発をやっているともとらえる事ができます。

自動化されるノウハウとは

では、自動化されるノウハウとは何でしょうか。大きく分けると4つ「定型手順」「設定値定義」「計算」そして「自動項目作成」があります。

定型手順

まさに「手順書にある作業」そのものです。ひたすら打ち込む手順を、プログラムにやらせます。自動かに依って作業時間そのものを短縮できるばかりか、手順をとばしてしまったり誤って入力してしまう事を防ぐことができます。お客様に安心を提供するMSPにとって、ミスは命取りです。そこを自動化で防げることは、非常に大切な事です。

設定値定義

ハードウェアやネットワークの環境によって、設定値が異なっています。そこを、ChefであればAttribute, Templateを用いて定型の設定を作成する事ができます。もちろんプログラムを直してもいいのですが、Attribute, Templateを変更する形にしておけばプログラムの動作試験を再度実施する必要はありません。自動化と柔軟性を両立させることができます。

計算

前回のブログ「「写経」から始めるChefクックブックの作成」が一つの例です。環境によって、動的ではあるものの計算式が決まっているものは、それこそプログラムにやらせてしまえば良いのです。電卓ではじくときに起きかねないミスや、そもそも電卓をはじく手間自体をなくすことができます。

自動項目作成

例えば、あるデーモンが動いていれば、そのデーモンの稼働状況監視するためにNagiosなどの運用監視ツールの監視項目を作成します。この項目登録を自動化するプログラムを用意すれば、監視すべき項目を自分で洗い出して登録する手間が軽減できます。そして、計算と同様、ミスのリスクや手間の軽減を行う事ができます。

留意している事

Cookbook 作成にあたって、次の3点「お客様の環境を傷つけない」「Cookbook の可読性に留意する」そして「Chef 以外の選択肢を捨てない」ことに留意して作っています。

お客様の環境を傷つけない

当社では、お客様の環境と隔離したディレクトリに Chef などのツールをインストールしています。

Chef は Ruby で動いている事は、みなさまご存知の通りです。自社で構築している環境であれば、gemで入れたり、オムニバスインストーラで入れてしまえばよいかもしれません。しかし、MSPはどの環境も「お客様」のものであります。従って、お客様の実行環境を傷つけることは最もやっては行けない事です。従って、gemで入れる事は、ライブラリの依存関係を操作してしまいかねないため、できません。また、オムニバスインストーラも/usr/binを操作してしまうため、お客様がもしChefを利用していた場合、その実行環境を傷つける可能性があります。

Cookbook の可読性に留意する

開発会社のような、エンジニアはほぼ全員プログラマであれば、それなりに凝った Cookbook を書いても良いかもしれません。しかし、MSPではそうとは限りません。そこで、自社で Cookbook を書く場合は、できるかぎりシンプルにすることで可読性を担保できるよう配慮しています。万一、問題が起こっても容易に追跡する事ができます。

また、コミュニティの Cookbook を採用する場合も、できる限りシンプルにまとめられているものを優先して利用するよう、心がけています。私がよく見ている観点は、OS別の処理分岐が少ないものであるかどうかです。結果的に、分岐が少ないとシンプルになっているものが多いように感じます。

Chef 以外の選択肢を捨てない

Chef は確かに便利です。一方で、RPMやaptなどのパッケージマネジメントシステムも引き続き利用しています。コンパイルが必要なミドルウェアなどは、事前にパッケージ化しておけばインストール時間の短縮につながります。それに、パッケージ作成の方がどちらかというと慣れている人もいます。また、適切に作っておけば細かく Cookbook を書く必要さえなくなります。いろいろな「引き出し」を持っておく事が大切かなと考えています。

今後について

Chef のお話は、「構築」を中心とした業務改善のアプローチが主となっています。しかし、MSPで最も大切な業務は「運用」です。その運用でも様々な自動化の取り組みを行っています。機会があれば、お話しできたらと思っています。

おわりに

ここまで、MSPにおけるChef利用にあたって、「導入の目的」「「開発会社」との状況の違い」「自動化されるノウハウとは」「留意している事」をお話ししてきました。ざっくりまとめますと、利用の目的は、CIの一環として利用することよりも、ノウハウをコードに落として自動化・ノウハウの共有を推進することがポイントとなっています。

「Chef」は、開発と運用が一体であることを実践を通じて伝えてくれる素晴らしいツールです。プログラムが苦手、という方もいるかもしれません。ただ、一方でミドルウェアの設定が苦手な方もいます。互いに手を取り合ってやっていけば、きっと昨日よりも素晴らしいシステム・サービスをお客様にご提供できるのではないでしょうか。

それでは、ごきげんよう。