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

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

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

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

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

パート1 ：CHEFによる自動化と構成管理とは パート2 ： RHEL /CentOS8/7にCHEFワークステーションをインストールする方法 パート3 ： RHEL /CentOS8/7にCHEFクライアントサーバーモデルをインストールする方法

このチュートリアルは、シェフがどのように行うかについての出発点を提供します Chefの作業、自動化、構成管理、アーキテクチャ、およびコンポーネント。

1。構成管理

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

構成管理ツールには、プッシュベースの2つのモデルがあります。 ＆プルベース 。 プッシュベース 、マスターサーバーは構成コードを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。シェフのアーキテクチャ

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

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

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

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

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

5。 Chefデプロイメントモデル

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

• サーバークライアント –本番環境への導入に使用されます。
• シェフゼロ –開発、テスト、およびPOCに使用されます。

6。シェフはどのように働いていますか？コードとしてのインフラストラクチャ

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

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

結論

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