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


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

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

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

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

このチュートリアルでは、Chefの動作、自動化、構成管理、アーキテクチャ、およびChefのコンポーネントに関する開始点を提供します。

1.構成管理

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

構成管理ツールには、PUSHベースとPULLベースの2つのモデルがあります。 PUSHベースでは、マスターサーバーが構成コードをサーバーにプッシュします。サーバーでは、PULLベースの個々のサーバーがマスターに接続して構成コードを取得します。 PUPPETとCHEFは広く使用されているPULLベースのモデルであり、ANSIBLEは人気のあるPUSHベースのモデルです。この記事では、CHEFについて説明します。

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

シェフはオープンソースの自動化プログラムであり、システム管理者は、組織の多数のサーバーやその他のデバイスでの展開、構成、管理、および進行中のタスクを簡単に自動化できます。

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

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

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

  • Chef WorkStation:Chefユーザーが構成を作成、テスト、および適用するためのローカル開発プラットフォーム。ローカルデスクトップ、Chef DK(開発キット)がインストールされたラップトップにすることができます。本番環境に昇格する前に、開発/テスト環境として使用できます。
  • Chef Server:chef-serverソフトウェアがインストールおよび構成されているサーバーです。 Chefのコードを管理し、ChefWorkstationから構成コードにアクセスする責任があります。 chefサーバーはLinuxマシンである必要があり、他のオペレーティングシステムをサポートしません。
  • Chefクライアント:Chefコードやバイナリ内の他の依存ファイルなどの構成の詳細についてChefサーバーに接続するサーバーがあります。 Chefサーバーからコードをプルし、ローカルにデプロイします。

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

以下は、主要なChefコンポーネントです。

  • リソースは、インフラストラクチャの管理に使用されるレシピの基本モジュールです。
  • 属性は、キーと値のペアの形式の設定です。
  • レシピは、ワークステーションで作成できる属性のコレクションです。これは、ChefコードとしてChefクライアントに適用できる一連のコマンドです。
  • レシピのコレクションはクックブックと呼ばれます。
  • ナイフは、ChefServerと対話するChefWorkstationのコマンドラインツールです。

5.シェフの配置モデル

Chefには2つのデプロイメントモデルがあります。

  • サーバークライアント–本番環境への導入に使用されます。
  • Chef Zero –開発、テスト、POCに使用されます。

6.シェフはどのように機能しますか?コードとしてのインフラストラクチャ

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

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

この記事では、構成管理とChef自動化ツールの基本的な概念を見てきました。今後の記事で、Chefのインストールのステップバイステップのプロセスを確認します。