CHEF による自動化と構成管理とは – パート 1

単純なシナリオを考えてみましょう。10 台の Redhat サーバーがあり、すべてのサーバーに「tecmint」ユーザーを作成する必要があります。直接的なアプローチでは、各サーバーにログインし、useradd コマンドを使用してユーザーを作成する必要があります。サーバーが数百台、数千台になると、すべてのサーバーに 1 台ずつログインすることは事実上不可能です。

このような場合に最初に思い浮かぶのは、スクリプトを作成し、そのスクリプトをサーバー上で実行させることです。これは実績のあるアプローチです。スクリプトには独自の欠点があります。スクリプトは組織で広く使用されていますが、スクリプト所有者が組織を離れた場合、維持するのが困難です。

スクリプトは異種環境では機能しません。スクリプトはタスクを達成するための命令的な方法であり、単純なタスクなどのために長いコードを記述する必要があります。この状況では、自動化および構成管理ツールなどの自動化および構成管理ツールを探す必要があります。シェフです。

Chef に関するこのシリーズ記事では、パート 1 ～ 3 で Chef Automation ツールのインストールと構成手順について説明し、次のトピックを扱います。

このチュートリアルでは、Chef の仕組み、自動化、構成管理、アーキテクチャ、および Chef のコンポーネントについての出発点を提供します。

1. 構成管理

構成管理はDevOps実践の重要な焦点です。ソフトウェア開発サイクルでは、すべてのサーバーをソフトウェアで構成し、開発サイクルを中断しないように適切に保守する必要があります。不適切な構成管理により、システムの停止、漏洩、データ侵害が発生する可能性があります。 構成管理ツールを使用すると、DevOps 主導の環境での精度、効率、速度が促進されます。

構成管理ツールには、プッシュベースとプルベースの 2 つのモデルがあります。 プッシュベースでは、マスターサーバーが設定コードをサーバーにプッシュし、ここでプルベースの個々のサーバーがマスターに連絡して設定コードを取得します。 PUPPET と CHEF は広く使用されている PULL ベースのモデルであり、ANSIBLE は人気のある PUSH ベースのモデルです。今回はシェフについて見ていきます。

2. シェフとは何ですか?

シェフ は、システム管理者が組織内の多数のサーバーやその他のデバイスにわたる展開、構成、管理、継続的なタスクを簡単な方法で自動化できるオープンソースの自動化プログラムです。

2008 年にOPSCODE として確立され、後にCHEF (Chef Automation ツール) に名前が変更されました。
これは、組織のインフラストラクチャ全体の構成の管理、自動化、調整に使用される Ruby ベースの自動化ツールです。
これはオープンソースプロジェクトであり、サーバークライアントとスタンドアロンの 2 つの展開モデルが付属しています。
Chef は、Ubuntu、Redhat/CentOS、Fedora、macOS、Windows、AIX などのさまざまなオペレーティングシステムをサポートしています。
Chef は宣言型で、ネイティブスクリプト言語よりもはるかに単純です。
継続的な展開を提供して、企業が市場の要件を常に最新の状態に保つことができるようにします。
シェフの主な責任は、定義された構成の状態を維持することです。
数十から数千のノードを簡単に管理するための独自の宣言言語を備えています。
Chef はクラウドに適応しており、クラウド上のインフラストラクチャと簡単に統合できます。
Chef は習得が簡単で、コミュニティにサポートされている強力な DevOps フレンドリーなツールです。

3. シェフのアーキテクチャ

Chef のアーキテクチャは 3 つの主要なセクションに分かれています。

Chef WorkStation: Chef ユーザーが構成を作成、テスト、適用するためのローカル開発プラットフォーム。 Chef DK (開発キット) がインストールされているローカルのデスクトップまたはラップトップにすることができます。運用環境に移行する前の開発/テスト環境として使用できます。
シェフサーバー: シェフサーバーソフトウェアがインストールされ、設定されているサーバーです。 Chef のコードを管理し、Chef Workstation から構成コードにアクセスする役割を果たします。シェフサーバーは Linux マシンである必要があり、他のオペレーティングシステムはサポートされません。
Chef クライアント: Chef サーバーに接続して、Chef コードやバイナリ内のその他の依存ファイルなどの設定の詳細を取得するサーバーがあります。 Chef サーバーからコードを取得し、ローカルにデプロイします。

4. シェフコンポーネント

以下は主要なシェフ コンポーネントです。

リソースは、インフラストラクチャを管理するために使用されるレシピの基本モジュールです。
属性は、キーと値のペアの形式の設定です。
レシピは、ワークステーションで作成できる属性のコレクションです。これは、Chef コードとして Chef クライアントに適用できるコマンドのセットです。
レシピを集めたものをクックブックといいます。
ナイフ は、Chef Server と通信する Chef Workstation のコマンドラインツールです。

5. シェフ展開モデル

Chef には 2 つの展開モデルがあります。

サーバークライアント – 運用環境の展開に使用されます。
Chef Zero – 開発、テスト、POC に使用されます。

6. シェフはどのように仕事をするのですか?コードとしてのインフラストラクチャ

Infrastructure as Code は、さまざまなインストール/展開と構成管理を自動的に実行できる IT インフラストラクチャ管理です。ここでは、すべての構成とインストールがコードとして記述されています。

Chef クライアント/ノードは、Chef サーバーへの登録と認証を行います。
Chef クライアント/ノードは定期的に Chef サーバーを調べます。認証プロセスは、シェフクライアントがシェフサーバーに保存されているデータにアクセスするたびに実行されます。
Ohai は、システム状態を判断するために Chef クライアントによって実行されるツールです。ノードの属性 (OS、メモリ、ディスク、CPU、カーネルなど) を検出し、次の情報を提供します。これらの属性はシェフクライアントに与えられます。 Ohai は Chef Client インストールの一部です。
クックブックまたは構成設定に変更がある場合、変更は Chef-Client に送信され、更新/インストールされます。
クックブックと設定は、コマンドラインツールナイフを通じて Chef Workstation を使用して Chef サーバーで更新されます。ワークステーションは、Knife を使用してすべてのポリシーを Chef サーバーにプッシュします。
各クライアント/ノードは Chef サーバーとの定期的なチェックを行うため、構成はサーバーの役割に従って個別に適用されます。例: Chef ノードでは、一部のノードはデータベースサーバーになり、一部のノードはゲートウェイサーバーになります。

結論

この記事では、構成管理と Chef 自動化ツールの基本概念について説明しました。今後の記事で、Chef のインストールの段階的なプロセスを見ていきます。