現場のDevOpsプログラムにChefを使用すれば、クラウドを使いこなすことが大幅に簡単になります。

Chefは、オープンソースのクラウド構成管理および展開用アプリケーションであり、クラウドや部門内データセンターにあるサーバーのオーケストレーションを支援します。システム管理者が単一のスタンドアロンサーバー向けに設計された管理プログラムで苦労しなくても、Chefがあれば、DevOpsで数十や数百のサーバーインスタンスを、この記事を読む間よりも短い時間で生成できます。

Chefを使用すると、プログラマとシステム管理者が共同作業できるようになります。開発者がアプリケーションを作成してから、ソフトウェアの展開方法を運用スタッフが理解するのを待つのではなく、Chefが両方のコミュニティにサービスを提供します。Chefでは、プロセスを手際の悪いリリースサイクルから継続的デリバリモデルに移行するために、DevOps移行の主要な目標である効率的で自動化されたワークフローを導入します。

その結果、既存のIT要員からさらに多くの成果を引き出せるようになり、IT部門のあらゆる動きが、間違いを減らしつつスピードアップします。さらに、(実世界ではしばしば起こる) 突然の問題にも、すばやく対処できます。

「クラウドの構成管理」は、Chefによって可能となる事柄の1つですが、これはインフラストラクチャをコードに変換することで行われます。結果として、このプロセスは、柔軟かつバージョン管理可能で、可読性の高い、テスト可能なものになります。Infrastructure as Codeでは、クラウドとオンプレミスの双方のリソースを管理できます。根本的に、Chefはインフラストラクチャとアプリケーションを自動化および管理するためのフレームワークです。具体的には、システム管理タスクは、クックブックとレシピと呼ばれる再利用可能な定義に変換されます。レシピ内で、Chefのユーザーは構成コードを記述して、システムの必要な状態を定義します。次に、そのコードと、コードが実行される特定のノードに関するデータがChefで処理され、必要な状態が実際にシステムの状態に一致するようになります。

 

自動化が必要な理由

システム管理者と開発者はシェルスクリプトや手動のインストール手順に満足していないのでしょうか。実際のところ、そうです。古いシステム管理や展開の手法は、まったくスケールできないからです。

具体的な例を見てみましょう。CEOが会社のe-コマースサイトを変更するように命じたとします。当然、開発者または運用担当者は、既存のe-コマースプログラムと新しいプログラムの両方でA/Bテストを実施することにします。従来のやり方では、サーバーをセットアップし、e-コマースソフトウェアを立ち上げて、データをロードし、テストユーザーのグループを手配します。これには時間がかかります。

自動化すれば、このプロセスをはるかにスケーラブルなものにすることができます。Chefを使用すると、既存のプラットフォームのクローンをテストプラットフォームに作成するだけで済みます。サーバーやクラスターを手動でセットアップする必要はありません。テストプラットフォームには、本番環境で使用しているパブリッククラウドを指定できます。セットアッププロセス全体は (時間、日、週単位ではなく) 分単位で完了します。

次に、修正したプログラムをユーザーコミュニティに展開し、すぐにフィードバックを得ることができます。新しいサイトデザインがうまくいかない場合でも、手動でロールバックする必要はありません。Chefを使用すれば、すべてのユーザーのプログラムを古い本番プログラムに自動的にロールバックして、再度試すことができます。

あるいは、クラウドのセットアップで何か新しいことを試すことを考えましょう。この場合、Chefに用意されている一般的な展開シナリオ向けのレシピが役立ちます。NGINXを展開して、WebサーバーとしてApacheよりもうまく動作するかどうかを確認するには、NGINXクックブックを使用して、NGINXをLinuxサーバーに展開します。

NGINXのエキスパートになる必要はありません。テストベッド環境にNGINIXをロールアウトし、独自のChefレシピを使用してWebプログラムを移植して、トランザクションのベンチマークを開始します。以上で完了です。

このようなことが可能になるのは、特にクラウド内で、多数の要素が仮想化されているためです。ChefのようなDevOpsプログラムは、仮想ITの領域で開発と運用の間のギャップを解消し、管理プロセスを自動化します。

その結果、自動化と展開が容易になり、信頼性が確保され、リソースの検証が自動化されます。

 

Chefの基本

Chefは任意のデータセンターやクラウドインフラストラクチャで使用することができ、Windows、エンタープライズLinuxディストリビューション、AIX、FreeBSD、Solaris、Cisco IO、Nexusといった複数のプラットフォームで動作します。Chefでサポートされるクラウドプラットフォームには、Amazon Web Services (AWS)、Google Cloud Platform、OpenStack、IBM Bluemix、HPE Cloud、Microsoft Azure、VMware vRealize Automation、Rackspaceなどがあります。

Chefのワークフローでは、最初に、チームの開発者やシステム管理者が自動化するタスクを定義します。レシピとクックブックでプロセスをキャプチャーし、Test Kitchen、ChefSpec、Foodcriticなどのツールで、それらのレシピとクックブックがテストされます。正しく動作するようになったレシピとクックブックは、knifeおよびchefコマンドラインツールを使用してChefサーバーに展開されます。

標準的なChef展開は、3つのコアコンポーネント (Chefサーバー、ワークステーション、ノード) で構成されます。

ワークステーションでは、クックブックに保存されるChefレシピを作成して編集します。Chefクックブックは、その名前が示すとおり、構成データおよびポリシー配布が含まれる関連レシピの集まりです。また、ワークステーションにはインフラストラクチャの構成ドキュメントのライブラリが保存されています。レシピの作成が完了したら、Chef Knifeを使用してChefサーバーにレシピを保存します。

Chefサーバーは、レシピ、クックブック、ノードのポリシー、役割、環境、ノードのメタデータのレポジトリです。ポリシーは、組織のビジネス要件と運用要件、プロセス、およびワークフローを、サーバーに保存された設定とオブジェクトにマップします。役割は、「Webサーバー」や「データベースサーバー」といったサーバータイプを定義します。環境は、開発、ステージング、本番環境といったプロセスのタイプを定義します。つまり、Chefサーバーにはインフラストラクチャの構成データがすべて保存されています。

Chefクックブックで最も重要なパーツは、そのレシピです。レシピは、Rubyの方言の1つであるドメイン固有言語 (DSL) で記述された小さなプログラムだと考えることができます。レシピのDSLはRuby DSLなので、Rubyで実行できることはすべて、レシピ内でも実行できます。このようなアプローチにより、Chefは初心者にとって使いやすいだけでなく、パワーユーザーがカスタマイズソリューションのコードを作成するために必要な柔軟性を備えています。

ゼロから作業を始める必要はありません。レシピをテンプレートとして使用して作業を開始できることは、重要なポイントです。3,000を超えるクックブックを活用して、Webサーバー、アプリケーションサーバー、データベースサーバー、その他のさまざまなタイプのサーバーをセットアップできます。その後、特定のニーズに応じてサーバーをカスタマイズします。

サーバーで必要となる状態のことを「シナリオ」と呼びます。たとえば、あるシナリオでは、特定のタイプのサーバーにLAMPスタックをインストールして構成するために必要なすべての手順を記述します。クックブック内のレシピには、使用するリソースと、それらのリソースの使用順序を指定します。

完成したレシピは、Chefサーバー上のクックブックに保存します。その後、レシピは、事前設定された定期的なスケジュールで発生する次のチェックイン時にノードと同期されます。

REST APIを使用すると、これらのレシピをノード (物理サーバーおよび仮想サーバー) とワークステーションで利用できるようになります。レシピと、関連するデータおよびインストラクションは、その後、ユーザーの指示によって自動的にノードに展開されます。

Chefクライアントはノード (実際のアプリケーションサーバーやWebサーバー) 上で動作し、knifeとAPIを使用してChefサーバーと通信します。

また、クライアントは、ノードに割り当てられたアクションを実行します。展開の構成作業は、サーバー上でなく、ほとんどがノード上で行われます。これにより、サーバーのボトルネックを避けることができ、Chefは大規模なノード展開にも対応できるようになります。

少し複雑に思われるかもしれませんので、例を挙げて説明しましょう。たとえば、Djangoに基づいたアプリケーションを展開する必要がある場合、まず、ワークステーション上でクックブックとレシピを作成します。この場合、Djangoに加えて、一般に、Apache Webサーバー、MySQLデータベース、memcached、RabbitMQ、Linuxディストリビューションも必要になります。

Djangoクックブックに、これらのサービスの詳細と展開方法が記述されたレシピを作成し、Chefサーバーにクックブックを保存します。クックブックのインストラクションは、サーバーからChefクライアントが動作するノードに展開されます。Djangoのセットアップが完了して実行されたら、次に、Djangoアプリケーションを展開するためのレシピとクックブックを作成します。

管理者や開発者がワークステーション上で行った変更は、サーバーに送信されます。変更内容がサーバーに到達したら、ノードに送信されるように手配します。このような仕組みにより、各マシンと個別に通信しなくても、レシピを変更することで、インフラストラクチャ全体にパッチやアップデートをロールアウトできます。

大部分のオープンソースツールと同様に、Chefは既存企業のサポートを受けています。Chefには利用できるバージョンが4つあります。Chef Basics (旧称: Open Source Chef。無償のオープンソースバージョン)、SaaS (Software-as-a-Service) Hosted Chef、Chef Automate (オンサイトChefサーバーを含む)、そして、Amazon Web Services専用のChefバージョンであるAWS OpsWorks for Chef Automateです。このバージョンでは、AWSでフルマネージド型Chefサーバーを提供します。各バージョンの価格は、サポート内容と可用性のレベルを反映したものになっています。

どのバージョンを選ぶにせよ、Chefの展開に手間はかかりません。Chefの開発企業は、無償の仮想サーバーをRed Hat Enterprise Linux (RHEL) 7またはCentOS 7、Windows Server 2012 R2、Ubuntu 14.04向けに提供しており、さまざまなクラウドや仮想マシンに対応することができます。あるいは、Chefをダウンロードすることもできます。Chef Development Kitのツールを使用すると、Debian、RHEL、MacOS、Ubuntu、およびWindows上でインフラストラクチャの開発とテストを行えます。

ChefとPuppetの比較

Chefは、Ansible、Puppet、Saltと並ぶ4大DevOpsツールの1つです。それぞれのツールには独自の利点があり、詳細な分析を行う価値がありますが、ここでは取り上げません。

DevOpsツールについて語るには、おそらくChefの最大のライバルであるPuppetについて簡単に説明する必要があるでしょう。Puppetではモデルベースのアプローチを採用しており、必要な構成の状態をPuppetマニフェストに記述します。次に、Puppetはサーバーに対し、必要な終了状態を達成するように指示します。

ChefとPuppetの最も明らかな相違点は、Chefが創造的な開発者を対象としているのに対し、Puppetは慎重なシステム管理者にとって最適なツールであるということでしょう。あるいは、Chefはコードに大きく依存しており、プログラミングによるアプローチで大規模なシステム管理に対応していると考えることができます。Puppetのモデルベースのアプローチでは、必要な構成の状態をPuppetマニフェストに記述することがシステム管理者に求められます。その上で、Puppetはサーバーに対し、必要な終了状態を達成するように指示します。

どちらのツールが最適であるかは、組織のチームによって異なります。各ツールの機能について詳しく調べて、ハンズオンの体験ができるカンファレンスへの参加を検討してください。選択の基準となるのは、ツールそのものよりもチームの取り組み方の問題だと言えます。どちらのツールであっても、適切なユーザーが扱えば非常にうまく機能します。

もちろん、Chefは万人向けとは言えません。Rubyを知らなければ、学習曲線は険しいものになります。また、その構造もシンプルではありません。大規模で複雑なコードベースを作成することができ、古いスタイルのシェルプログラム一式よりもトラブルシューティングは簡単ですが、それでもデバッグに時間がかかる可能性があります。

Chefの代わりとなるようなツールでは、手動による作業の割合が多くなります。従来のシステム管理ツールを使用して、複雑なアプリケーションを、関連するパッチやアップデート、セキュリティホールと共に多数のサーバーに展開することになるでしょう。そのような作業は誰も望んでいません。Chefを使用すれば、はるかに生産的な作業に時間を費やすことができます。

会社のITが長期的な成功を収めるには、Chefが提供するソリューションが最適であることがわかるでしょう。

 

ChefでDevOpsを実現: リーダーへのアドバイス

• Chefは、ワークフローを自動化することで、ソフトウェアのリリースサイクルに継続的デリバリモデルを適用します。
• システム管理タスクは、クックブックやレシピ、必要な状態に向けた再利用可能な構成ステップとして保存されます。
• Chefは、クラウドのエコシステム全体にわたって幅広い業界のサポートを受けており、思いつく限りのあらゆるプラットフォームで動作します。

 

_{この記事/コンテンツは、記載されている特定の著者によって書かれたものであり、必ずしもHewlett Packard Enterpriseの見解を反映しているとは限りません。}